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

On 11/15/25 16:57, Tom Lane wrote:
> Nico Williams <nico(at)cryptonector(dot)com> writes:
>> Some unsolicited advice:
>> ...
>> But here you can just use the order that the SQL uses. It gives the
>> author some power.
>
> If that's the approach you want, it's been possible for decades:
> "set join_collapse_limit = 1" and away you go. I don't feel a
> need to invent a different version of that for star schemas.
>
> I do not think this patch should have ambitions beyond the stated
> one of avoiding useless join-order search effort. If you try to
> load more than that onto the plate you'll probably end in failure.
>

FWIW I certainly agree with this. The motivation is to speed up planning
with starjoin-like queries, and that's still the primary goal. If it
could handle more complex cases (snowflake, inverse starjoin), great.
But I have no ambition to make it somehow generic and much more complex.

The main thing I'm really unsure about is what to do about joins that
increase the cardinality. AFAICS that's the only possible regression if
we simply move joins with dimensions at the end. Not sure what to do
about that before the actual join search ...

regards

--
Tomas Vondra