Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id d172e2cf-3990-f25a-5067-b52c85c68d6e@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] path toward faster partition pruning  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
Hi David.

On 2018/03/25 14:32, David Rowley wrote:
> On 25 March 2018 at 18:28, David Rowley <david.rowley@2ndquadrant.com> wrote:
>> The attached delta applies on top of v39 plus delta1.
> 
> Sorry, the attached should do this. Ignore the last attachment.

I have incorporated both of your delta1 and delta2_1 patches.

Your proposed change to determine the cross-type comparison function OID
during planning itself is a good one, although I wasn't sure why it was
done only for the <> operators.  I also implemented that for
PartitionPruneStepOp steps.

Also, I started thinking that implementing pruning using <> operators with
a PartitionPruneCombineOp was not such a great idea.  That needed us to
add argexprs and argcmpfns to that struct, which seemed a bit odd.  I
defined a new pruning node type called PartitionPruneStepOpNe, which still
seems a bit odd, but given that our support for pruning using <> is quite
specialized, that may be fine.

I added a bunch of hopefully informative comments in partprune.c and for
the struct definitions of pruning step nodes.

Please find attached find a new version.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: new function for tsquery creartion
Next
From: Masahiko Sawada
Date:
Subject: Re: PATCH: Exclude unlogged tables from base backups