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-28 08:13:19
Message-ID: ad949722-6adb-4c11-bd7c-33ac1db29ed6@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Here is the rebased patch set, requested by the commitfest platform.

The following development directions:

1. As this 'lazy join' machinery has a massive footprint in regression tests, I
think it makes sense to investigate a cost-based way.
It isn't strictly necessary, because a gated NestLoop doesn't add any
perceptible overhead, and, for the sake of simplicity and safety, this
optimisation might remain opportunistic. Also, a cost-based approach leads to
more mistakenly picked NestLoop paths in the case of wrong estimates, as well as
more intensive usage when gated NestLoop paths are more efficient than HashJoin
or MergeJoin paths (I have such cases in the pocket already).

2. Platform-independent EXPLAIN output.
The first patch adds the platform_independent_explain routine that hides
unstable memory size. It is a little annoying considering that different
regression tests solve it separately. Considering that extensions also need such
a routine, it might be useful to invent a single routine that post-processes
EXPLAIN (ANALYZE, BUFFERS OFF, TIMING OFF, SUMMARY OFF) and removes any
platform-dependent information at each regression test that needs that. This
topic might be discussed and done in a separate thread.

3. pg_plan_advice patch.
It seems annoying that something outside the planner core performs a formal plan
check, not a semantic one (if possible), adds extra work, and almost undermines
the extensible approach for new planner features. But we still need to identify
the correct way to extend this machinery - now it is quite a formal fix.

--
regards, Andrei Lepikhov,
pgEdge

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Steven Niu 2026-07-28 08:19:54 Re: PSQL schema "describe" \dn is not escaping quotes
Previous Message Yilin Zhang 2026-07-28 07:47:29 Re: Grab bag of smaller OpenSSL fixups