Timeline for DB2 Materialised Query Table performance problems
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 6, 2016 at 13:40 | comment | added | Chris Aldrich | @kovika - at the risk of a flame war, I would say that MQTs are not trouble. They just need to be used in the right place. The right tool for the right job. I wouldn't use them just anywhere. But they have their uses. I have used an MQT in combination with a view to successfully assist with moving data back and forth between two systems with federation. It was very handy there. So, again, the right place for it is handy. But there are downsides to them and in the wrong spot they can be trouble. | |
| Dec 18, 2013 at 23:45 | comment | added | sapatos | thanks for the advice Kovica - I found that the MQT was very slow until I put indexes on all the source table primary keys that are required in the select statement of the definition. Once the indexes were on it was pretty quick. For transactions that were hitting the source tables I was seeing between 5-18% degradation. I worked out our performance savings vs update degrades was still in our benefit so we're sticking with them for the time being. (especially as my boss says we have to :) | |
| Dec 17, 2013 at 23:05 | review | First posts | |||
| Dec 17, 2013 at 23:44 | |||||
| Dec 17, 2013 at 22:50 | history | answered | kovica | CC BY-SA 3.0 |