|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
>> 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
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
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
+ * on add_path() to give additional decision for path removel
+ * 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
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|Next Message||Seino Yuki||2020-11-09 11:09:29||Re: Feature improvement for pg_stat_statements|
|Previous Message||Amit Kapila||2020-11-09 10:52:07||Re: logical streaming of xacts via test_decoding is broken|