Re: [HACKERS] advanced partition matching algorithm forpartition-wise join - Mailing list pgsql-hackers

From amul sul
Subject Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Date
Msg-id CAAJ_b94B3D15HQ=oPxPER0f8bv=WyTkhSKUpKLmLX4AYpURCrQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] advanced partition matching algorithm forpartition-wise join  (amul sul <sulamul@gmail.com>)
Responses Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
List pgsql-hackers
Attached is the rebase atop the latest master head(a9056cc637f).

On Tue, Nov 5, 2019 at 6:44 PM amul sul <sulamul@gmail.com> wrote:


On Fri, Nov 1, 2019 at 3:58 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
On Thu, Oct 31, 2019 at 6:49 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> Attached is an updated version.  If no objections, I'll merge this
> with the main patch [1].

Done.  Attached is a new version of the patch.

Other changes: in generate_matching_part_pairs(), I changed variable
names to match other functions, simplified assertions, and
adjusted/added comments a bit.

Thanks for the update version.  

A query and comments for v25:

583 + * The function returns NULL if we can not find the matching pair of
 584 + * partitions. This happens if 1. multiple partitions on one side match with
 585 + * one partition on the other side. 2. a given partition on the outer side
 586 + * doesn't have a matching partition on the inner side. We can not support the
 587 + * first case since we don't have a way to represent multiple partitions as a
 588 + * single relation (RelOptInfo) and then perform join using the ganged
 589 + * relation. We can not support the second case since the missing inner
 590 + * partition needs to be represented as an empty relation and we don't have a
 591 + * way to introduce empty relation during join planning after creating paths
 592 + * for all the base relations.
 593 + */
 594 +PartitionBoundInfo
 595 +partition_bounds_merge(int partnatts,

I think the second condition mention for partition_bounds_merge() looks
outdated, do you think we should remove that or am I missing something here?
---

1768 +
1769 +       /*
1770 +        * If this is an outer join, the merged partition would act as the
1771 +        * default partition of the join; record the index in *default_index
1772 +        * if not done yet.
1773 +        */
1774 +       if (jointype == JOIN_LEFT || jointype == JOIN_ANTI ||
1775 +           jointype == JOIN_FULL)
1776 +       {

As decided need to replace this list by IS_OUTER_JOIN(jointype).
---

2020 +       if (jointype == JOIN_LEFT || jointype == JOIN_FULL ||
2021 +           jointype == JOIN_ANTI)
2022 +       {

Same as the previous.
---

I tried a coverage testing and tried to adjust & add a few tests to improved the
code coverage for the v25 patch. Please have a look at the attached 0002 & also
attach the coverage output with & without this patch, TWIMW.

0001 is the same v25 patch, reattaching to make CFbot happy.

Regards,
Amul

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: Etsuro Fujita
Date:
Subject: Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.