Re: LATERAL

On Sun, Oct 18, 2009 at 11:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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