Re: should we have a fast-path planning for OLTP starjoins? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: should we have a fast-path planning for OLTP starjoins?
Date
Msg-id 1751009.1738974197@sss.pgh.pa.us
Whole thread Raw
In response to Re: should we have a fast-path planning for OLTP starjoins?  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
Tomas Vondra <tomas@vondra.me> writes:
> Instead, I was thinking about the "other" joins (if there are any), that
> may add or remove rows. AFAIK we want to join the dimensions at the
> place with the lowest cardinality - the discussion mostly assumed the
> joins would only reduce the cardinality, in which case we'd just leave
> the dimensions until the very end.

> But ISTM that may not be necessarily true. Let's say there's a join that
> "multiplies" each row. It'll probably be done at the end, and the
> dimension joins should probably happen right before it ... not sure.

I thought the idea here was to get rid of as much join order searching
as we could.  Insisting that we get the best possible plan anyway
seems counterproductive, not to mention very messy to implement.
So I'd just push all these joins to the end and be done with it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Question about UpdateFullPageWrites() at the end of recovery.
Next
From: M vd H
Date:
Subject: BgBufferSync(): clarification about reusable_buffers variable