From: Tom Lane <tgl@sss.pgh.pa.us>
To: Manfred Koizar <mkoi-pg@aon.at>
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 17:46:03 -0400
Message-ID: <28348.1061502363@sss.pgh.pa.us> (raw)
In-Reply-To: <p0dakv05anhoqgmmgipbmpk9dhsdcm73pe@4ax.com>
References: <20030821102627.C51705-100000@megazone.bigpanda.com>
<25062.1061498540@sss.pgh.pa.us>
<p0dakv05anhoqgmmgipbmpk9dhsdcm73pe@4ax.com>
Manfred Koizar <mkoi-pg@aon.at> writes:
> 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?
Yeah, I know, but I see no easy way to verify this (where "easy" means
"doesn't take an unreasonable amount of time"). A naive check would
take O(N^2) time, putting you right back where you started. Even a
smart check would surely take more time per item than one hashtable probe.
I'm also concerned about how much the planner would have to assume about
the semantics of the operators in order to prove the conditions are
mutually exclusive.
Finally, I suspect that once we get rid of the O(N^2) behavior in the
executor, we will find that the next biggest bottleneck is in the
planner; adding more work for it to do per OR-clause item will make
things worse not better.
regards, tom lane
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: tgl@sss.pgh.pa.us, mkoi-pg@aon.at, sszabo@megazone.bigpanda.com, oderbolz@ecologic.de, pgsql-hackers@postgreSQL.org
Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b
In-Reply-To: <28348.1061502363@sss.pgh.pa.us>
* 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