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

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>

To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>

Cc: Robert Haas <robertmhaas@gmail.com>, Antonin Houska <ah@cybertec.at>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2018-02-09T05:56:28Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Suppress unused-variable warning.
- 401418ca6a68 13.0 landed
Allow partitionwise joins in more cases.
- c8434d64ce03 13.0 landed
Avoid crash in partitionwise join planning under GEQO.
- 7ad6498fd5a6 12.0 cited
- d70c147fa217 11.3 cited
Disable support for partitionwise joins in problematic cases.
- 7cfdc77023ad 12.0 cited
Add plan_cache_mode setting
- f7cb2842bf47 12.0 cited
Add test for partitionwise join involving default partition.
- 4513d3a4be0b 12.0 cited
Revise API for partition_rbound_cmp/partition_rbound_datum_cmp.
- b0229235564f 11.0 landed

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