Re: Strange workaround for slow query

On Wed, Mar 10, 2010 at 5:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> 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