On Sun, Oct 18, 2009 at 11:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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.
Yeah, this was what I was driving at, but I got turned around in my
head and was explaining it incorrectly.
> 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.
You could probably convince me that a merge join is not going to be
too useful (how often can you want a merge join on the inner side of a
nested loop? ... especially when there are partial index scans
involved) but I think your last point here is well-taken. We've
certainly turned a corner from "it's just the exponential growth in
the number of join paths to consider that's a problem". :-)
...Robert
