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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Dec 20, 2025 at 5:49 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> It seems we have to identify these joins _before_ we actually start the
>> main optimizer. We can identify restriction joins since we see the
>> restriction in the query, and we can identify neutral joins because of
>> foreign keys. How do we identify expansion joins? Is it all the joins
>> which are not the previous types?

> We unfortunately have no way to identify these joins before we
> actually start the main optimizer; that's not how the code works. I'm
> not sure if there's a reasonable way to do better, because whether the
> join inflates or reduces the row count can't be known independently of
> the join order in general, even though in practice it often can.

I think the core idea of this proposal is to improve cases where
we *can* know that; where we can't, just do what we've always done.
Not handling every case isn't a fatal objection, as long as the
patch doesn't spend much time to discover that it can't help.

Having said that, I'm starting to wonder whether "do this stuff in a
separate pass before the main optimizer" is the wrong structural
decision. Should we be injecting the logic at some later point
where we've gathered more information? At least in principle,
we should be able to build all base-relation Paths before we start
to think about join order; would having those help?

regards, tom lane