Re: should we have a fast-path planning for OLTP starjoins? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: should we have a fast-path planning for OLTP starjoins?
Date
Msg-id aRu8e25cJYh6uXq8@momjian.us
Whole thread Raw
In response to Re: should we have a fast-path planning for OLTP starjoins?  (Bruce Momjian <bruce@momjian.us>)
List 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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Use streaming read I/O in BRIN vacuuming
Next
From: Chao Li
Date:
Subject: Re: [PATCH] Add pg_get_database_ddl() function to reconstruct CREATE DATABASE statement