From: Kevin Grittner <Kevin.Grittner@wicourts.gov>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-performance@postgresql.org
Cc: Andrea Olson <Aolson.CCAP.Courts@wicourts.gov>
Cc: Bill Severson <BSEVERS.CCAP.Courts@wicourts.gov>
Cc: John Hutchins <jhutchi.CCAP.Courts@wicourts.gov>
Cc: Randy Peterson <RPETERS.CCAP.Courts@wicourts.gov>
Cc: Shannon Spranger <ssprang.CCAP.Courts@wicourts.gov>
Subject: Re: EXISTS optimization
Date: Fri, 23 Mar 2007 17:30:27 -0500
Message-ID: <46040EB2.EE98.0025.0@wicourts.gov> (raw)
In-Reply-To: <20070323222641.GD9623@svana.org>
References: <4603C1A3.EE98.0025.0@wicourts.gov>
<25339.1174686582@sss.pgh.pa.us>
<20070323222641.GD9623@svana.org>
I don't understand -- TRUE OR UNKNOWN evaluates to TRUE, so why would the IN need to continue? I'm not quite following the rest; could you elaborate or give an example? (Sorry if I'm lagging behind the rest of the class here.)
-Kevin
>>> Martijn van Oosterhout <kleptog@svana.org> 03/23/07 5:26 PM >>>
On Fri, Mar 23, 2007 at 05:49:42PM -0400, Tom Lane wrote:
> We don't currently try to flatten EXISTS into a unique/join plan as we
> do for IN. I seem to recall not doing so when I rewrote IN planning
> because I didn't think it would be exactly semantically equivalent,
> but that was awhile ago. Right at the moment it seems like it ought
> to be equivalent as long as the comparison operators are strict.
Wasn't it due to the fact that IN needs to scan through all
possibilites anyway because of its interaction with NULL, whereas
EXISTS can stop at the first row?
That would mean the subquery to be materialised would not be equivalent
if it called any non-immutable functions. It's also much less clear to
be a win in the EXISTs case. But then, that's a costs issue the planner
can deal with...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/> From each according to his ability. To each according to his ability to litigate.
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: Kevin.Grittner@wicourts.gov, tgl@sss.pgh.pa.us, kleptog@svana.org, pgsql-hackers@postgresql.org, Aolson.CCAP.Courts@wicourts.gov, BSEVERS.CCAP.Courts@wicourts.gov, jhutchi.CCAP.Courts@wicourts.gov, RPETERS.CCAP.Courts@wicourts.gov, ssprang.CCAP.Courts@wicourts.gov
Subject: Re: EXISTS optimization
In-Reply-To: <46040EB2.EE98.0025.0@wicourts.gov>
* 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