Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id CA+HiwqEhtmOdw0YYiZw9nip=NbnNzzpqqntTURieg_684RJbOQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Runtime Partition Pruning
List pgsql-hackers
On Sat, Apr 7, 2018 at 1:31 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-04-07 13:26:51 +0900, Amit Langote 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.
>
> I've not followed this thread/feature at all, but I don't find the
> comments atop partprune.c even remotely sufficient. Unless there's an
> README hidden or such hidden somewhere?

Sorry there isn't a README and I agree partprune.c's header comment
could be improved quite a bit.

Just to be clear, that's the fault of the patch that was already
committed earlier today (9fdb675fc "Faster partition pruning"), not
this patch, which just extends partition.c's functionality to
implement additional planner and executor support for runtime pruning.

I'm drafting a patch that expands the partprune.c comment and will post shortly.

Thanks,
Amit


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning