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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <jnasby(at)upgrade(dot)com>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: should we have a fast-path planning for OLTP starjoins?
Date: 2025-02-04 22:49:58
Message-ID: 694461.1738709398@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <jnasby(at)upgrade(dot)com> writes:
> On Tue, Feb 4, 2025 at 3:42 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>> Perhaps requiring (INNER JOIN + FK) or (LEFT JOIN + PK) would be enough
>> to make this work for most cases, and then the rest would simply use the
>> regular join order algorithm.

> As long as the join is still happening there doesn't appear to be a
> correctness issue here, so I'm not sure mandating FKs makes sense.
> The reason this matters is that highly concurrent FK checks can get VERY
> expensive (due to the cost of creating multiXacts). While it'd be great to
> fix that issue the reality today is it's not uncommon for people to remove
> FKs because of the high performance penalty.

Meh. If we don't apply this optimization when there's no FK, we have
not made those folks' life any worse. If we apply it despite there
being no FK, we might choose a materially worse plan than before, and
that *will* make their lives worse.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2025-02-04 22:52:00 Re: Commitfest app release on Feb 17 with many improvements
Previous Message Peter Eisentraut 2025-02-04 22:36:53 Re: Virtual generated columns