From: Manfred Koizar <mkoi-pg@aon.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Dani Oderbolz <oderbolz@ecologic.de>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b
Date: Thu, 21 Aug 2003 23:18:04 +0200
Message-ID: <p0dakv05anhoqgmmgipbmpk9dhsdcm73pe@4ax.com> (raw)
In-Reply-To: <25062.1061498540@sss.pgh.pa.us>
References: <20030821102627.C51705-100000@megazone.bigpanda.com>
<25062.1061498540@sss.pgh.pa.us>
On Thu, 21 Aug 2003 16:42:20 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>The point is that given
> WHERE a = 1 OR b = 1
>you could create a plan that first indexscans on a, then indexscans on
>b --- but you mustn't return any tuples in the second scan that you
>already returned in the first. IndexNext solves this by evaluating the
>prior-scan index conditions to see if they are true.
WHERE a = 1 OR b = 2
and
WHERE a = 1 OR a = 2
are totally different things. In the latter case you don't have to
check prior conditions because the conditions are mutually exclusive.
Is this reasonably easy to find out at plan creation time?
Yes, I changed your example to make my point clear, because
WHERE a = 1 OR a = 1
has its own set of problems.
Servus
Manfred
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-sql@postgresql.org
Cc: mkoi-pg@aon.at, tgl@sss.pgh.pa.us, sszabo@megazone.bigpanda.com, oderbolz@ecologic.de, pgsql-hackers@postgreSQL.org
Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b
In-Reply-To: <p0dakv05anhoqgmmgipbmpk9dhsdcm73pe@4ax.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