Re: [HACKERS] Runtime Partition Pruning

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

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

To: Amit Langote <amitlangote09@gmail.com>

Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Jesper Pedersen <jesper.pedersen@redhat.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Beena Emerson <memissemerson@gmail.com>, Robert Haas <robertmhaas@gmail.com>, amul sul <sulamul@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Dilip Kumar <dilipbalaut@gmail.com>

Date: 2018-04-07T08:45:58Z

Lists: pgsql-hackers

Attachments

v23-0001-Provide-infrastructure-to-allow-partition-prunin.patch (application/octet-stream) patch v23-0001
v23-0002-Add-bms_prev_member-function.patch (application/octet-stream) patch v23-0002
v23-0003-Allow-unneeded-Append-subnodes-to-be-pruned-at-e.patch (application/octet-stream) patch v23-0003
v23-0004-Allow-unneeded-MergeAppend-s-subnodes-to-be-prun.patch (application/octet-stream) patch v23-0004

On 7 April 2018 at 16:26, Amit Langote <amitlangote09@gmail.com> wrote:
> On Sat, Apr 7, 2018 at 11:26 AM, David Rowley
> <david.rowley@2ndquadrant.com> wrote:
>> Everything else looks fine from my point of view.
>
> Me too, although I still think having struct names PartitionPruning
> and PartitionRelPruning is going to be  a bit confusing.  We should
> think about naming the latter to something else.  I suggested
> PartitionPruningDispatch(Data), but David doesn't seem to like it.
> Maybe, PartitionPruneState, because it parallels the
> PartitionPruneInfo that comes from the planner for every partitioned
> table in the tree.

Ok, so I've gone and done this.

PartitionPruning has become PartitionPruneState
PartitionRelPruning has become PartitionPruningData

I've changed pointers to PartitionPruneStates to be named prunestate,
sometimes having the node prefix; as_, ma_, in these cases prune and
state are separated with a _ which seems to be the general rule for
executor state struct members.

Generally, pointers to PartitionPruningData are now named pprune.
Hopefully, that's ok, as this was the name previously used for
PartitionPruning pointers.

I applied the patch to get rid of as_noop_scan in favour of using a
special as_whichplan value. There was already one special value
(INVALID_SUBPLAN_INDEX), so seemed better to build on that rather than
inventing something new. This also means we don't have to make the
AppendState struct and wider too, which seems like a good thing to try
to do.

I made all the fixups which I mentioned in my review earlier and also
re-removed the resultRelation parameter from make_partition_pruneinfo.
It sneaked back into v22.

v23 is attached.

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

Commits

Initialize ExprStates once in run-time partition pruning
- 1957f8dabf8d 11.0 landed
Add bms_prev_member function
- 5c0675215e15 11.0 landed
Support partition pruning at execution time
- 499be013de65 11.0 landed
Document partprune.c a little better
- 971d7ddbe19a 11.0 landed
Fix crash in pg_replication_slot_advance
- 6f1d723b6359 11.0 cited
Add parallel-aware hash joins.
- 1804284042e6 11.0 cited
Fix typo.
- 487a0c1518af 11.0 cited
Allow --with-bonjour to work with non-macOS implementations of Bonjour.
- 9b9cb3c4534d 11.0 cited
Mention need for --no-inc-recursive in rsync command
- 2c74e6c1dcc5 11.0 cited