Re: pgsql: Support partition pruning at execution time

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

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-09T20:34:56Z
Lists: pgsql-hackers
David Rowley wrote:

> Okay, I've written and attached a fix for this.  I'm not 100% certain
> that this is the cause of the problem on pademelon, but the code does
> look wrong, so needs to be fixed. Hopefully, it'll make pademelon
> happy, if not I'll think a bit harder about what might be causing that
> instability.

Pushed it just now.  Let's see what happens with pademelon now.

> The misleading comment claimed we unset the extern params so we didn't
> perform pruning again using these. I'd failed to update this comment
> after I realised that we still need to attempt to prune again with the
> external params since quals against the partition key may actually
> contain a mix of exec and external params, which would mean that it's
> only possible to prune partitions using both types of params. No
> actual code needs to be updated since the 2nd pass of pruning uses
> "allparams" anyway. We could actually get away without the bms_free()
> and set to NULL in the lines below the comment, but I wanted some way
> to ensure that we never write any code which calls the function twice
> on the same PartitionPruneState, but maybe I'm just overly paranoid
> there.

Pushed this earlier today, thanks.

-- 
Á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