Re: Asymmetric partition-wise JOIN - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: Asymmetric partition-wise JOIN
Date
Msg-id CALNJ-vTbOA9fLWoKp1aH-kuwZ3SEPGvW72c50hzEieqvYGOWcw@mail.gmail.com
Whole thread Raw
In response to Re: Asymmetric partition-wise JOIN  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Responses Re: Asymmetric partition-wise JOIN  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Re: Asymmetric partition-wise JOIN  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
List pgsql-hackers


On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov <a.lepikhov@postgrespro.ru> wrote:
On 18/6/21 15:02, Alexander Pyhalov wrote:
> Andrey Lepikhov писал 2021-05-27 07:27:
>> Next version of the patch.
>> For searching any problems I forced this patch during 'make check'
>> tests. Some bugs were found and fixed.
>
> Hi.
> I've tested this patch and haven't found issues, but I have some comments.
Thank you for review!
> Variable names - child_join_rel and child_join_relids seem to be
> inconsistent with rest of the file
fixed

> When build_child_join_rel() can return NULL?
Fixed
> Missing word:
> each bitmapset variable will large => each bitmapset variable will be large
Fixed
> What hook do you refer to?
Removed> You've changed function to copy appinfo, so now comment is
incorrect.
Thanks, fixed> Do I understand correctly that now parent_relids also
contains relids of
> relations from 'global' inner relation, which we join to childs?
Yes

--
regards,
Andrey Lepikhov
Postgres Professional
Hi,

relations because it could cause CPU and memory huge consumption
during reparameterization of NestLoop path.

CPU and memory huge consumption -> huge consumption of CPU and memory 

+ * relation. Return List of such RelOptInfo's. Return NIL, if at least one of
+ * these JOINs are impossible to build.

at least one of these JOINs are impossible to build. -> at least one of these JOINs is impossible to build.

+            * Can't imagine situation when join relation already exists. But in
+            * the 'partition_join' regression test it happens.
+            * It may be an indicator of possible problems.

Should a log be added in the above case ?

+is_asymmetric_join_capable(PlannerInfo *root,

is_asymmetric_join_capable -> is_asymmetric_join_feasible

Cheers

pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Next
From: David Rowley
Date:
Subject: Re: Removed extra memory allocations from create_list_bounds