| 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.
| 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 |