Re: Partition-wise join for join between (declaratively) partitioned tables

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Partition-wise join for join between (declaratively) partitioned tables
Date: 2017-08-21 07:03:49
Message-ID: CAFjFpRd9Vqh_=-Ldv-XqWY006d07TJ+VXuhXCbdj=P1jukYBrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 16, 2017 at 5:21 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Aug 16, 2017 at 3:31 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>> There are two ways we can do this
>> 1. In expand_inherited_rtentry(), remember (childRTE and childRTIndex)
>> or just childRTIndex (using this we can fetch childRTE calling
>> rtfetch()) of intermediate partitioned tables. Once we are done
>> expanding immediate children, call expand_inherited_rtentry()
>> recursively on this list.
>>
>> 2. expand_inherited_tables() scans root->parse->rtable only upto the
>> end of original range table list. Make it go beyond that end,
>> expanding any new entries added for intermediate partitions.
>>
>> FWIW, the first option allows us to keep all AppendRelInfos
>> corresponding to one partitioned relation together and also expands
>> the whole partition hierarchy in one go. Second will require minimal
>> changes to expand_inherited_rtentry(). Both approaches will spend time
>> scanning same number of RTE; the first will have them in different
>> lists, and second will have them in root->parse->rtable. I don't see
>> one being more attractive than the other. Do you have any opinion?
>
> I don't like option (2). I'm not sure about option (1). I think
> maybe we should have two nested loops in expanded_inherited_rtentry(),
> the outer one iterating over partitioned tables (or just the original
> parent RTE if partitioning is not involved) and then inner one looping
> over individual leaf partitions for each partitioned table. Probably
> we'd end up wanting to move at least some of the logic inside the
> existing loop into a subroutine.

I originally thought to provide it along-with the changes to
expand_inherited_rtentry(), but that thread is taking longer. Jeevan
Chalke needs rebased patches for his work on aggregate pushdown and
Thomas might need them for further review. So, here they are. The last
two patches in this set implement the advanced partition matching
algorithm. Those patches are here for ready reference. One can observe
that patch doesn't change much of the basic partition-wise join
implementation. I am starting a new thread for discussing the advanced
partition matching algorithm.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Attachment Content-Type Size
pg_dp_join_patches_v26.tar.gz application/x-gzip 143.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-08-21 07:13:16 advanced partition matching algorithm for partition-wise join
Previous Message Mithun Cy 2017-08-21 06:42:52 Re: Proposal : For Auto-Prewarm.