Planner : anti-join on left joins

Nicolas Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com>

From: Nicolas Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com>
To: pgsql-hackers@lists.postgresql.org
Date: 2025-12-31T09:59:26Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Reduce LEFT JOIN to ANTI JOIN using NOT NULL constraints

Attachments

Hi,

while writting a book in 2025, i read an played with the postgresql code.
now my book is finished and i think that maybe a next step is to try to
patch postgresql for some optimisations. I'm a beginner about postgresql
code (but i patched a lot of opensource programs while working on a linux
distro).

this first email aim is to discuss about the fact that this kind of code
(just a draft here) have a chance to be commited or not (once comments
added, reident, cleaning, ...). Details about each implementation could be
discussed later.

There are some optimisations at the planner level that are not mandatory
when you know how it works, but all the year, i get query to optimize
because people doesn't know the pg internals or write not well written
queries. So, the patches i would like to suggest are more "non mandatory
optimisations".

like:
- detect anti join on "a left join b where x is null" where x is a non null
var b (b being a rte)
this is the object of the attached patched.
it is not finished, but working for a demonstation (this is a quick and
dirty patch just to try if i were able to do it).
it shows me that it has drawbacks : for example : it requires to know the
details on some tables sooner on the planner, (and thus, sometimes, before
we detect that we could just remove a table => so we build some tables for
nothing except optimisations)

- remove unrequirered distinct, group by (select distinct id_unique from
people;)
- remove double order (select * from (select * from a order by x) order by
y) (where * doesn't containt functions based on row nums)
- detect anti join on "not in(...)"
- have a way to view the rewritten query ? (like explain)

and so on.