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

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, James Hunter <james.hunter.pg@gmail.com>, Richard Guo <guofenglinux@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-18T00:23:23Z
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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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