Re: should we have a fast-path planning for OLTP starjoins?

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Tomas Vondra" <tomas(at)vondra(dot)me>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: should we have a fast-path planning for OLTP starjoins?
Date: 2026-06-01 16:20:48
Message-ID: 3979b2d1-0eef-456d-ab78-c216342c8ccb@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 1, 2026, at 17:35, Tomas Vondra wrote:
> The other idea is that Joel Jacobson's patch with KEY joins might allow
> proving more joins are 1:1, not just joins on foreign keys. But I
> haven't thought about that very much, and I'm not sure it's very useful
> for such joins (it's probably not a starjoin-like query, and does not
> have so many number of join orders).

I find this thread very interesting, and like Tomas explained,
I'm interested in examining if there could possibly be an opportunity
for some shared infrastructure here. I intend to conduct such research
in the upcoming weeks, and report back with my findings.

Just to clarify one thing; a key join is always backed by an underlying
foreign key (referential constraint). What I think Tomas means with
"not just joins on foreign keys" is that that key joins not only works
between two base tables, but also through derived tables.
To explain what that means, maybe an example is easiest,
a good one I recommend is: https://keyjoin.org/#sec7.3.1

/Joel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-06-01 16:41:07 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Previous Message Lucas Jeffrey 2026-06-01 16:02:43 Re: [PATCH] Fix segmentation fault caused by reentrancy in RI_Fkey_cascade_del (ri_triggers.c)