Re: Asymmetric partition-wise JOIN

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Kohei KaiGai <kaigai(at)heterodb(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Asymmetric partition-wise JOIN
Date: 2020-11-30 14:43:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 09.11.2020 13:53, Anastasia Lubennikova wrote:
> On 21.08.2020 09:02, Andrey V. Lepikhov wrote:
>> On 7/1/20 2:10 PM, Daniel Gustafsson wrote:
>>>> On 27 Dec 2019, at 08:34, Kohei KaiGai <kaigai(at)heterodb(dot)com> wrote:
>>>> The attached v2 fixed the problem, and regression test finished
>>>> correctly.
>>> This patch no longer applies to HEAD, please submit an rebased version.
>>> Marking the entry Waiting on Author in the meantime.
>> Rebased version of the patch on current master (d259afa736).
>> I rebased it because it is a base of my experimental feature than we
>> don't break partitionwise join of a relation with foreign partition
>> and a local relation if we have info that remote server has foreign
>> table link to the local relation (by analogy with shippable extensions).
>> Maybe mark as 'Needs review'?
> Status update for a commitfest entry.
> According to cfbot, the patch fails to apply. Could you please send a
> rebased version?
> This thread was inactive for quite some time. Is anyone going to
> continue working on it?
> I see some interest in the idea of sharable hash, but I don't see even
> a prototype in this thread. So, probably, it is a matter of a separate
> discussion.
> Also, I took a look at the code. It looks like it needs some extra
> work. I am not a big expert in this area, so I'm sorry if questions
> are obvious.
> 1. What would happen if this assumption is not met?
> +         * MEMO: We assume this pathlist keeps at least one
> AppendPath that
> +         * represents partitioned table-scan, symmetric or asymmetric
> +         * partition-wise join. It is not correct right now, however,
> a hook
> +         * on add_path() to give additional decision for path removel
> allows
> +         * to retain this kind of AppendPath, regardless of its cost.
> 2. Why do we wrap extract_asymmetric_partitionwise_subjoin() call into
> PG_TRY/PG_CATCH? What errors do we expect?
> 3. It looks like a crutch. If it isn't, I'd like to see a better
> comment about why "dynamic programming" is not applicable here.
> And shouldn't we also handle a root->join_cur_level?
> +                /* temporary disables "dynamic programming" algorithm */
> +                root->join_rel_level = NULL;
> 4. This change looks like it can lead to a memory leak for old code.
> Maybe it is never the case, but again I think it worth a comment.
> -    /* If there's nothing to adjust, don't call this function. */
> -    Assert(nappinfos >= 1 && appinfos != NULL);
> +    /* If there's nothing to adjust, just return a duplication */
> +    if (nappinfos == 0)
> +        return copyObject(node);
> 5. extract_asymmetric_partitionwise_subjoin() lacks a comment
> The new status of this patch is: Waiting on Author
Status update for a commitfest entry.

This entry was inactive during this CF, so I've marked it as returned
with feedback. Feel free to resubmit an updated version to a future

Anastasia Lubennikova
Postgres Professional:
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-11-30 14:48:26 Re: pgbench - test whether a variable exists
Previous Message Heikki Linnakangas 2020-11-30 14:42:20 Re: Index Skip Scan (new UniqueKeys)