Tomas Vondra <tomas@vondra.me> writes:
>> The interesting thing about this is we pretty much have all the
>> infrastructure for detecting such FK-related join conditions
>> already. Possibly the join order forcing could be done with
>> existing infrastructure too (by manipulating the joinlist).
> Maybe, interesting. I've ruled out relying on the FKeys early in the
> coding, but I'm sure there's infrastructure the patch could use.
It would be very sad to do that work twice in a patch that purports
to reduce planning time. If it's done too late to suit you now,
could we move it to happen earlier?
> What kind of "manipulation" of the joinlist you have in mind?
Right now, if we have four tables to join, we have a joinlist
(A B C D). (Really they're integer relids, but let's use names here.)
If we decide to force C to be joined last, it should be sufficient to
convert this to ((A B D) C). If C and D both look like candidates for
this treatment, we can make it be (((A B) C) D) or (((A B) D) C).
This is pretty much the same thing that happens if you set
join_collapse_limit to 1 and use JOIN syntax to force a join order.
In fact, IIRC we start out with nested joinlists and there is some
code that normally flattens them until it decides it'd be creating
too large a sub-problem. I'm suggesting selectively reversing the
flattening.
regards, tom lane
