Re: Removing unneeded self joins - Mailing list pgsql-hackers

From Andrey V. Lepikhov
Subject Re: Removing unneeded self joins
Date
Msg-id 41f6fa78-e4a5-bd2a-d817-8dc2060ef47c@postgrespro.ru
Whole thread Raw
In response to Re: Removing unneeded self joins  (Zhihong Yu <zyu@yugabyte.com>)
List pgsql-hackers
On 7/16/21 12:28 AM, Zhihong Yu wrote:
> 
> 
> On Thu, Jul 15, 2021 at 8:25 AM Zhihong Yu <zyu@yugabyte.com 
> <mailto:zyu@yugabyte.com>> wrote:
>     bq. We can proof the uniqueness
> 
>     proof -> prove
Fixed
> 
>     1. Collect all mergejoinable join quals looks like a.x = b.x
> 
>       quals looks like -> quals which look like
> 
>     For update_ec_sources(), the variable cc is not used.
Fixed
> +   *otherjoinquals = rjoinquals;
> 
> Maybe rename rjoinquals as ojoinquals to align with the target variable 
> name.
Agree, fixed
> 
> +   int k; /* Index of kept relation */
> +   int r = -1; /* Index of removed relation */
> 
> Naming k as kept, r as removed would make the code more readable (remain 
> starts with r but has opposite meaning).
I think it is correct now: k - index of inner (keeping) relation. r - of 
outer (removing) relation.
> 
> +               if (bms_is_member(r, info->syn_righthand) &&
> +                   !bms_is_member(k, info->syn_righthand))
> +                   jinfo_check = false;
> +
> +               if (!jinfo_check)
> +                   break;
> 
> There are 4 if statements where jinfo_check is assigned false. Once 
> jinfo_check is assigned, we can break out of the loop - instead of 
> checking the remaining conditions.
Fixed
> 
> +           else if (!innerrel_is_unique(root, joinrelids, outer->relids,
> 
> nit: the 'else' is not needed since the if block above it goes to next 
> iteration of the loop.
Fixed
> 
> +           /* See for row marks. */
> +           foreach (lc, root->rowMarks)
> 
> It seems once imark and omark are set, we can come out of the loop.
Maybe you right. fixed.

-- 
regards,
Andrey Lepikhov
Postgres Professional

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
Next
From: Ronan Dunklau
Date:
Subject: pg_receivewal starting position