Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>, Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
Mark Dilger <mark.dilger@enterprisedb.com>, amul sul <sulamul@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>,
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>,
Dmitry Dolgov <9erthalion6@gmail.com>, Antonin Houska <ah@cybertec.at>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-04-09T06:33:29Z
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 Thu, Apr 9, 2020 at 2:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Etsuro Fujita <etsuro.fujita@gmail.com> writes: > > Yeah, partition_bounds_merge() is currently called only from > > try_partitionwise_join(), which guarantees that the strategies are the > > same. > If there's only one caller and there's not likely to ever be more, > then I tend to agree that you don't need the assertion. It seems unlikely that partition_bounds_merge() will be called from more places in the foreseeable future, so I'd still vote for removing the assertion. Best regards, Etsuro Fujita