Re: advanced partition matching algorithm for partition-wise join

Antonin Houska <ah@cybertec.at>

From: Antonin Houska <ah@cybertec.at>

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

Cc: pgsql-hackers@postgresql.org

Date: 2017-09-07T14:04:14Z

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

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

> I have fixed the issues which were marked as TODOs in the attached
> patches. Also, I have included your test change patch in my series of
> patches.

I've noticed that partition_bounds_merge() is called twice from
make_join_rel():

 * build_join_rel -> build_joinrel_partition_info -> partition_bounds_merge

 * try_partition_wise_join -> partition_bounds_merge

Is this intentional, or just a thinko?

-- 
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at