| 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 |
| Message-ID: | 54825f4e-8461-faf9-cac5-e6ce5f6f877a@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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.
Thanks,
Amit
| 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 |