On Wed, Jan 21, 2015 at 4:31 PM, Amit Langote <amitlangot...@gmail.com> wrote: > On Wednesday, January 21, 2015, Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> >> Does it happen only when parallel_seqscan_degree > max_worker_processes? > > > I have max_worker_processes set to the default of 8 while parallel_seqscan_degree is 4. So, this may be a case different from Thom's. >
I think this is due to reason that memory for forming tuple in master backend is retained for longer time which is causing this statement to take much longer time than required. I have fixed the other issue as well reported by you in attached patch. I think this patch is still not completely ready for general purpose testing, however it could be helpful if we can run some tests to see in what kind of scenario's it gives benefit like in the test you are doing if rather than increasing seq_page_cost, you should add an expensive WHERE condition so that it should automatically select parallel plan. I think it is better to change one of the new parameter's (parallel_setup_cost, parallel_startup_cost and cpu_tuple_comm_cost) if you want your statement to use parallel plan, like in your example if you would have reduced cpu_tuple_comm_cost, it would have selected parallel plan, that way we can get some feedback about what should be the appropriate default values for the newly added parameters. I am already planing to do some tests in that regard, however if I get some feedback from other's that would be helpful. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
parallel_seqscan_v5.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers