Re: Partition-wise join for join between (declaratively)partitioned tables
От | Ashutosh Bapat |
---|---|
Тема | Re: Partition-wise join for join between (declaratively)partitioned tables |
Дата | |
Msg-id | CAFjFpRf9MsG8LTrAjgQmpFpj1F4_FTWYJvsn5biWH0wNHh4gGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On Fri, Mar 24, 2017 at 1:57 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.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
Вложения
В списке pgsql-hackers по дате отправления: