Robert Haas <robertmh...@gmail.com> writes:
> I think you should only ever join an incomplete inner-indexscan path
> to (1) another inner-indexscan path or (2) the cheapest total path for
> *exactly* the future-join requirement. Anything else doesn't seem
> productive.
I don't see any reason to constrain the form of joins before the
future-join requirement. Once you get to the join that satisfies
that requirement, obviously you must implement it as a nestloop
with the inner-indexscan path on the inside. But there shouldn't
be any more constraint beyond that one for that join, either:
* you might want a fast-start plan not cheapest total
* sort orderings of the outer path might be useful
We know that sort ordering of the inner indexscan or its joins
won't be useful once we reach the future-join level, so it might
be possible to discard paths that are not cheapest total cost
below that level. The problem is to distinguish sort orderings
that are useful within joins below that level. You could avoid that
if you could convince yourself that there's no point in ever doing
a mergejoin at such a level, but I don't think I believe that.
It may well be that there's no point in being too tense about this issue
anyway. The planner will only consider early joins to rels that have
join clauses to the rel with the inner-indexscan path. There probably
won't be that many of them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
