这个sql怎么优化!

myfriend2010

结果出来了:
不设置 current query optimization
--           4561588 rows inserted in 4046.70 secs
设置set current query optimization 0;
--               4561588 rows inserted in 6529.09 secs.

[ 本帖最后由 myfriend2010 于 2008-5-7 13:51 编辑 ]

myfriend2010

恩,单分区的SORTHEAP= 1555(4k) 大约6M,4个分区大小也就是24M,差了好几个数量级!

原帖由 unixnewbie 于 2008-5-7 12:31 发表


Don't forget you're running DPF. That 8xxMB is just a total across all the partitions.

wangzhonnew

看来估计没有什么好的方法提高性能了，MSJOIN应该是expected。如果可能尽量增大sort heap

应该是单分区8xx MB per sort吧，那个TQ可是在最上面呢

askgyliu

三个五百万的TABLE JOIN实际并不很大。

4561588 rows inserted in 4046.70 secs

感觉是不行。

target table的TABLESPACE是SMS还是DMS？PARTITION KEY也是CUST_ID吧？

还，TARGET TABLE是空的，还是里面已经有很多数据了？

unixnewbie

原帖由 wangzhonnew 于 7/5/2008 21:10 发表
看来估计没有什么好的方法提高性能了，MSJOIN应该是expected。如果可能尽量增大sort heap

应该是单分区8xx MB per sort吧，那个TQ可是在最上面呢

嗯，应该是单分区的数据，除了你给出的证据，还有第一个explain最后也有“Source for statistics:                 Single Node”的字样。

如果实在要提高性能，且不能增加内存的话，如果cust_id很连续且不在乎storage消耗的话，用range cluster table。这样就不需要在每个tascan后做额外的sort+tbscan。从第一个explain中反映的io估算情况来开，每次额外的sort+tbscan都double了原来tbscan的IO。

myfriend2010

原帖由 askgyliu 于 2008-5-7 20:16 发表
三个五百万的TABLE JOIN实际并不很大。

4561588 rows inserted in 4046.70 secs

感觉是不行。

target table的TABLESPACE是SMS还是DMS？PARTITION KEY也是CUST_ID吧？

还，TARGET TABLE是空的，还是里面已经有很多数据了？

target table的TABLESPACE是SMS,PARTITION KEY=CUST_ID

TARGET TABLE为自定义的一个临时表！

myfriend2010

现在我考虑的是这个softheap怎么增加！？

SHEAPTHRES增加4倍和单分区SORTHEAP增加一倍？是不是可以这么理解？

wangzhonnew

hey, since the result set is relativly small (only 4.5 million rows), possible to create MQT for it?
taking the row width = 1500, 4.5 million took around 6-10G disk space

wangzhonnew

原帖由 askgyliu 于 2008-5-7 21:16 发表
三个五百万的TABLE JOIN实际并不很大。

4561588 rows inserted in 4046.70 secs

感觉是不行。

target table的TABLESPACE是SMS还是DMS？PARTITION KEY也是CUST_ID吧？

还，TARGET TABLE是空的，还是里面已经有很多数据了？

3个五百万的join开销的确不大，但是3个五百万的排序就恐怖了 ：）

wangzhonnew

恭喜！您刚拣到ITPUB送出的新年红包。25PUB币!