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 <kai...@heterodb.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
commitfest.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
