From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: slow IN() clause for many cases |
Date: | 2005-10-15 22:27:36 |
Message-ID: | 8764ryfmav.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > I would fear queries like
>
> > SELECT * from tab WHERE x IN (1,2,3) LIMIT 1
>
> > Which ought to be instantaneous would become potentially slow.
>
> Why? They certainly wouldn't be any slower than they are now.
Well currently they get rewritten to use OR which does a single index scan
which I assumed returned rows as soon as it finds them like it does for
regular range lookup index scans. Is that assumption wrong?
The bitmap scan has to traverse all the index entries for matching records
before it can fetch the first record. So it wouldn't be a fast-start plan. Not
as bad as performing a sort step or anything like that of course.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-10-15 22:34:18 | Re: A costing analysis tool |
Previous Message | Tom Lane | 2005-10-15 22:06:01 | Re: A costing analysis tool |