Horton

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

Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>

View thread
From: Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Etsuro Fujita <etsuro.fujita@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kuntal Ghosh <kuntalghosh.2007@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.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-10T15:20:37Z
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 →

  1. Suppress unused-variable warning.

  2. Allow partitionwise joins in more cases.

  3. Avoid crash in partitionwise join planning under GEQO.

  4. Disable support for partitionwise joins in problematic cases.

  5. Add plan_cache_mode setting

  6. Add test for partitionwise join involving default partition.

  7. Revise API for partition_rbound_cmp/partition_rbound_datum_cmp.

On Fri, 10 Apr 2020 at 20:44, Jeff Janes <jeff.janes@gmail.com> wrote:

> On Thu, Apr 9, 2020 at 10:04 AM Ashutosh Bapat <
> ashutosh.bapat.oss@gmail.com> wrote:
>
>> On Thu, Apr 9, 2020 at 12:03 PM Etsuro Fujita <etsuro.fujita@gmail.com>
>> wrote:
>> >
>> > 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.
>>
>> When I wrote that function, I had UNION also in mind. A UNION across
>> multiple partitioned relations will be partitioned if we can merge the
>> partition bounds in a sensible manner. Of course the current structure
>> of that function looks more purposed for join, but it's not difficult
>> to convert it to be used for UNION as well. In that case those set of
>> functions will have many more callers. So, I will vote to keep that
>> assertion now that we have it there.
>>
>
> In that case, we really should add the PG_USED_FOR_ASSERTS_ONLY to make
> the compiler happy.
>
>
Attaching my patch again. It doesn't need PG_USED_FOR_ASSERTS_ONLY as well.
Kuntal has confirmed that this fixes the warning for him.

-- 
Best Wishes,
Ashutosh