On Sun, Oct 18, 2009 at 11:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
