From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yeb Havinga <yebhavinga@gmail.com>
Cc: sverhagen@wps-nl.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Strange workaround for slow query
Date: Wed, 10 Mar 2010 17:41:35 -0500
Message-ID: <603c8f071003101441g4b116429t5044db4c52c7a32f@mail.gmail.com> (raw)
In-Reply-To: <21592.1268260640@sss.pgh.pa.us>
References: <OF6136AD9B.D40F3AF5-ONC12576E2.002D5763-C12576E2.002FBD70@imtechrelay.nl>
<4B976229.7030407@gmail.com>
<OFAD6B66E9.A0DAC161-ONC12576E2.0033EEEB-C12576E2.0033F903@imtechrelay.nl>
<4B977045.6040604@gmail.com>
<OF4ACE0533.8EF639EC-ONC12576E2.0039BD09-C12576E2.003A2A20@imtechrelay.nl>
<4B977CD3.5030402@gmail.com>
<603c8f071003101355r155a3078p7962360d0167895d@mail.gmail.com>
<21592.1268260640@sss.pgh.pa.us>
On Wed, Mar 10, 2010 at 5:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: robertmhaas@gmail.com, tgl@sss.pgh.pa.us, yebhavinga@gmail.com, sverhagen@wps-nl.com
Subject: Re: Strange workaround for slow query
In-Reply-To: <603c8f071003101441g4b116429t5044db4c52c7a32f@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox