Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1J4Ja1PYV8ZhfwyQKw=1q=ZbAcf62p9WSp1EpZ_cuOHiQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Parallel Seq Scan
Re: Parallel Seq Scan
List pgsql-hackers
On Wed, Jan 21, 2015 at 4:31 PM, Amit Langote <amitlangote09@gmail.com> wrote:
> On Wednesday, January 21, 2015, Amit Kapila <amit.kapila16@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
Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2
Next
From: Andrew Gierth
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)