Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Илья Жарков <izharkov1243(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, eng eng <pspetrov91(at)gmail(dot)com>
Subject: Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table
Date: 2026-07-03 10:53:11
Message-ID: bb73a0a0-70e6-46a1-900b-55dd75c2669d@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30/06/2026 10:20, Andrei Lepikhov wrote:
> See the new version of the patch attached. I treat this version still as a 'draft'.
This is the updated version of the feature.

- Merged into the existing Result logic. Added an Assert to check that
resconstantqual is a List or NULL, which documents the implicit AND contract at
the point where it is assumed. The combined qual list now uses
order_qual_clauses(), so clauses are executed in cost order.

- Parallel-safety handling reworked. That walk was redundant: the gating clauses
are a subset of the join's restrictlist, whose safety build_join_rel() already
folded into the join path's parallel_safe. Both branches now simply assign
best_path->jpath.path.parallel_safe, matching create_gating_plan()'s pattern

- Fixed compatibility with pg_plan_advice. I still do not understand why a
built-in extension should limit the possible plan choices, since this adds extra
development work and pushes most planner extension modules out of the market.
For now, I have only made a small correction until we discuss this further.

- Also, I passed all the updated tests. We have an impressive diff that shows
the benefits of cost-based decision-making. But this implementation is a clear
win while still leaving room for an optimiser-side version in the future. Since
the path-based implementation is more invasive, it makes sense to consider it
only if another use case for the GatingPath node appears. Seems nice enough to
be added to the next commitfest.

--
regards, Andrei Lepikhov,
pgEdge

Attachment Content-Type Size
v1-0001-Gate-the-NestLoop-inner-side-with-outer-only-join.patch text/plain 50.9 KB
v1-0002-pg_plan_advice-look-through-gating-Results-on-the.patch text/plain 1.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-07-03 10:54:37 Re: Tepid: selective index updates for heap relations
Previous Message Ashutosh Bapat 2026-07-03 10:39:20 Re: PROPERTY GRAPH pg_dump ACL minimization