> 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. > (Please point out me if my understanding is incorrect.)
What happen if dynamic background worker process tries to reference temporary tables? Because buffer of temporary table blocks are allocated on private address space, its recent status is not visible to other process unless it is not flushed to the storage every time. Do we need to prohibit create_parallelscan_paths() to generate a path when target relation is temporary one? Thanks, -- NEC OSS Promotion Center / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
