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

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, 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-03-24 12:24:36
Message-ID: CAFjFpRf9MsG8LTrAjgQmpFpj1F4_FTWYJvsn5biWH0wNHh4gGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 24, 2017 at 1:57 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> Hi Ashutosh,
>
> On 2017/03/23 21:48, Ashutosh Bapat wrote:
>>>> I have fixed all the issues reported till now.
>
> In patch 0007, the following code in have_partkey_equi_join() looks
> potentially unsafe:
>
> /*
> * If the clause refers to different partition keys from
> * both relations, it can not be used for partition-wise join.
> */
> if (ipk1 != ipk2)
> continue;
>
> /*
> * The clause allows partition-wise join if only it uses the same
> * operator family as that specified by the partition key.
> */
> if (!list_member_oid(rinfo->mergeopfamilies,
> part_scheme->partopfamily[ipk1]))
> continue;
>
> What if ipk1 and ipk2 both turn out to be -1? Accessing
> part_schem->partopfamily[ipk1] would be incorrect, no?

Thanks for the report. Surprising this should have crashed sometime,
but didn't ever. Neither it showed wrong output for queries where
partition keys were not part of equi-joins. The reason being
partopfamily[-1] had 0 in it, which when tested again
list_member_oid(rinfo->mergeopfamilies, ..) returned false. Attached
patches fix this code.

Also, I have fixed few grammar mistakes, typos, renamed variables in
PartitionSchemeData to match those in PartitionKey. I have squashed
the patches introducing IS_JOIN_REL, IS_OTHER_REL, IS_SIMPLE_REL into
one.

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

Attachment Content-Type Size
pg_dp_join_patches_v14.zip application/zip 64.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-03-24 12:30:32 Re: Monitoring roles patch
Previous Message Stephen Frost 2017-03-24 12:18:04 Re: increasing the default WAL segment size