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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, James Hunter <james(dot)hunter(dot)pg(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, 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-11-18 00:23:23
Message-ID: aRu8e25cJYh6uXq8@momjian.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 14, 2025 at 09:52:41PM -0500, Bruce Momjian wrote:
> On Sat, Nov 15, 2025 at 01:41:04AM +0100, Tomas Vondra wrote:
> > > And then there is the problem of detecting when this happens.
> > >
> > > I think my big question is, when we join A->B->C->D, we do a lot of work
> > > in the optimizer to figure out what order to use, but when we do A->B,
> > > A->C, A->D, why are we spending the same amount of optimizer effort?
> > >
> >
> > I'm sorry, I don't quite understand what's the question here. What does
> > A->B->C->D mean, exactly?
>
> It means table A joins B, and B joins C, and C joins D. I can see that
> as a much harder problem, and one we have code for in the optimizer,
> than A joining to B, C, and D.

I guess fundamentally it is the case of splitting a big problem into
smaller ones, e.g., 2 + 3 + 3 = 8, but 2! * 3! * 3! = 72 and 8! = 40320.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-11-18 00:28:23 Re: [PATCH] Add pg_get_database_ddl() function to reconstruct CREATE DATABASE statement
Previous Message Masahiko Sawada 2025-11-18 00:20:10 Re: Use streaming read I/O in BRIN vacuuming