Re: Asymmetric partition-wise JOIN

On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)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