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

From David Rowley
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id CAKJS1f96m-VMW-ViAXOdV-T8h_KRdrCUmADYNrhh2hySPz5Y=Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] Runtime Partition Pruning
List pgsql-hackers
On 7 January 2018 at 00:03, David Rowley <david.rowley@2ndquadrant.com> wrote:
> I've fixed this in the attached, but I did so by calling
> adjust_appendrel_attrs() from the nodeAppend.c, which did, of course,
> mean that the AppendRelInfo needed to be given to the executor. I was
> also a bit unsure what exactly I should be doing in primnodes.h, since
> I've put PartitionPruneInfo in there, but AppendRelInfo is not. I
> stuck a quick declaration of AppendRelInfo in primnode.h with an XXX
> comment so we don't forget to think about that again.

Actually, this was not a very smart fix for the problem. It seems much
better to make the prune qual part of PartitionPruneInfo and just have
the planner translate the qual to what's required for the partition
that the PartitionPruneInfo belongs to. This means we no longer need
to use the Append's qual to store the prune qual and that all the
pruning information for one partition is now neatly in a single
struct.

I've attached a patch which does things like this.

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

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: MCV lists for highly skewed distributions
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Refactoring identifier checks to consistently use strcmp