Horton

Re: pgsql: Support partition pruning at execution time

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Gierth <andrew@tao11.riddles.org.uk>, pgsql-committers@lists.postgresql.org
Date: 2018-04-17T19:26:49Z
Lists: pgsql-hackers 
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.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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