On Wed, Mar 10, 2010 at 5:37 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Robert Haas <robertmhaas@xxxxxxxxx> writes: >> It does seem like once the materialize step is done we could notice >> that the tuplestore is empty and, given that uses no outer variables >> or parameters and therefore will never be re-executed, we could skip >> the rest of the index scan. > > Yeah, the same thing occurred to me while looking at this example. > > Right now, nodeNestloop is not really aware of whether the inner scan > depends on any parameters from the outer scan, so it's a bit hard to > determine whether the join can be abandoned. However, I have 9.1 > plans to change that --- I'd like to get rid of the current > pass-the-outer-tuple-to-ReScan hack entirely, in favor of having > nodeNestloop explicitly set PARAM_EXEC parameters for the inner scan. > Once that's in, it would be pretty easy to apply this optimization. > (I've added a note to my private TODO file about it.) Oh, cool. I was thinking about working on that exact project (getting rid of the outer tuple stuff) per some of our earlier conversations, but I don't understand the code well enough so it is likely to be exceedingly slow going if I have to do it. > Another possible objection is that if the inner scan has any volatile > functions in its quals, it might yield a different result upon rescan > even without parameters. However, since we are already willing to stick > a Materialize node on it at the whim of the planner, I don't see how > such a short-circuit in the executor would make things any worse. +1. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
