From: Greg Stark <gsstark@mit.edu>
To: pgsql-hackers@postgresql.org
Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b
Date: 22 Aug 2003 11:28:55 -0400
Message-ID: <87k795iudk.fsf@stark.dyndns.tv> (raw)
In-Reply-To: <28348.1061502363@sss.pgh.pa.us>
References: <20030821102627.C51705-100000@megazone.bigpanda.com>
<25062.1061498540@sss.pgh.pa.us>
<p0dakv05anhoqgmmgipbmpk9dhsdcm73pe@4ax.com>
<28348.1061502363@sss.pgh.pa.us>
Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
But time spent in the planner doesn't matter if you're using prepared queries
which is true for OLTP applications where there are very few queries being
executed many many times. I hear web sites are quite popular these days.
I missed the beginning of this thread so I'm not sure if it's relevant. But
wouldn't it be possible to just check if all the clauses and see if they're
using precisely the same index with an equality type operator? That won't
catch things like "a BETWEEN 1 AND 2 OR a BETWEEN 5 AND 6" but it will catch
things like "a IN (1,2,3,4,5,6)". And I don't see how it wouldn't be linear
in the number of clauses.
--
greg
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: gsstark@mit.edu, pgsql-hackers@postgresql.org
Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b
In-Reply-To: <87k795iudk.fsf@stark.dyndns.tv>
* 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