Re: [HACKERS] advanced partition matching algorithm for partition-wise join

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Date: 2018-02-09 05:56:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2018/02/09 14:31, Ashutosh Bapat wrote:
>> I also noticed that a later patch adds partsupfunc to PartitionScheme,
>> which the pruning patch needs too. So, perhaps would be nice to take out
>> that portion of the patch. That is, the changes to PartitionScheme struct
>> definition and those to find_partition_scheme().
> I am not sure whether a patch with just that change and without any
> changes to use that member will be acceptable. So leaving this aside.

I asked, because with everything that I have now changed in the partition
pruning patch, one would need to pass these FmgrInfo pointers down to
partition bound searching functions from the optimizer. If the changes to
add partsupfunc to the optimizer were taken out from your main patch, the
pruning patch could just start using it. For now, I'm making those
changes part of the pruning patch.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2018-02-09 06:03:46 Re: Proposal: partition pruning by secondary attributes
Previous Message Amit Langote 2018-02-09 05:32:12 Re: non-bulk inserts and tuple routing