Re: [HACKERS] Runtime Partition Pruning
От | Jesper Pedersen |
---|---|
Тема | Re: [HACKERS] Runtime Partition Pruning |
Дата | |
Msg-id | 308e5f60-cf13-bf1e-73bc-4e40f5128baf@redhat.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Runtime Partition Pruning (David Rowley <david.rowley@2ndquadrant.com>) |
Список | pgsql-hackers |
Hi, On 04/07/2018 04:45 AM, David Rowley wrote: > 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. > Passes check-world. Changing explain.c to "Subplans Removed" as suggested by you in [1] is a good idea. [1] https://www.postgresql.org/message-id/CAKJS1f99JnkbOshdV_4zoJZ96DPtKeHMHv43JRL_ZdHRkkVKCA%40mail.gmail.com Best regards, Jesper
В списке pgsql-hackers по дате отправления: