On Fri, Sep 18, 2015 at 9:45 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Sep 18, 2015 at 1:33 PM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: >> >> On Thu, Sep 3, 2015 at 8:21 PM, Amit Kapila <amit.kapil...@gmail.com> >> wrote: >> > >> > Attached, find the rebased version of patch. >> >> Here are the performance test results: >> >> Query selectivity HashAgg HashAgg >> (million) + seqscan(ms) + >> parallel seq scan(ms) >> 2 >> workers 4 workers 8 workers >> $1 <= '001' 0.1 16717.00 7086.00 >> 4459.00 2912.00 >> $1 <= '004' 0.4 17962.00 7410.00 >> 4651.00 2977.00 >> $1 <= '008' 0.8 18870.00 7849.00 >> 4868.00 3092.00 >> $1 <= '016' 1.5 21368.00 8645.00 >> 6800.00 3486.00 >> $1 <= '030' 2.7 24622.00 14796.00 13108.00 >> 9981.00 >> $1 <= '060' 5.4 31690.00 29839.00 26544.00 >> 23814.00 >> $1 <= '080' 7.2 37147.00 40485.00 35763.00 >> 32679.00 >> > > I think here probably when the selectivity is more than 5, then it should > not have selected Funnel plan. Have you by any chance changed > cpu_tuple_comm_cost? If not, then you can try by setting value of > parallel_setup_cost (may be 10) and then see if it selects the Funnel > Plan. Is it possible for you to check the cost difference of Sequence > and Funnel plan, hopefully explain or explain analyze should be sufficient?
Yes, I changed cpu_tuple_comm_cost to zero to observe how parallel seq scan performs in high selectivity. Forgot to mention in the earlier mail. Overall the parallel seq scan performance is good. >> And also attached perf results for selectivity of 0.1 million and 5.4 >> million cases for analysis. >> > > I have checked perf reports and it seems that when selectivity is more, it > seems to be spending time in some kernel calls which could be due > communication of tuples. Yes. And also in low selectivity with increase of workers, tas and s_lock functions usage is getting increased. May be these are also one of the reasons for scaling problem. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers