Re: should we have a fast-path planning for OLTP starjoins?
| От | Bruce Momjian |
|---|---|
| Тема | Re: should we have a fast-path planning for OLTP starjoins? |
| Дата | |
| Msg-id | aRu8e25cJYh6uXq8@momjian.us обсуждение исходный текст |
| Ответ на | Re: should we have a fast-path planning for OLTP starjoins? (Bruce Momjian <bruce@momjian.us>) |
| Список | 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 по дате отправления: