Horton

Re: pgsql: Support partition pruning at execution time

David Rowley <david.rowley@2ndquadrant.com>

View thread View on postgr.es
From: David Rowley <david.rowley@2ndquadrant.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Gierth <andrew@tao11.riddles.org.uk>, pgsql-committers@lists.postgresql.org
Date: 2018-04-17T21:30:50Z
Lists: pgsql-hackers 
On 18 April 2018 at 07:26, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> David Rowley wrote:
>
>> I've made another pass over the nodeAppend.c code and I'm unable to
>> see what might cause this, although I did discover a bug where
>> first_partial_plan is not set taking into account that some subplans
>> may have been pruned away during executor init. The only thing I think
>> this would cause is for parallel workers to not properly help out with
>> some partial plans if some earlier subplans were pruned. I can see no
>> reason for this to have caused this particular issue since the
>> first_partial_plan would be 0 with and without the attached fix.
>
> Pushed this.

Thanks!

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Update Append's idea of first_partial_plan

  2. Fix IndexOnlyScan counter for heap fetches in parallel mode

  3. Fix incorrect logic for choosing the next Parallel Append subplan

  4. Minor comment updates

  5. Attempt to stabilize partition_prune test output.

  6. Support partition pruning at execution time