From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Martin Sarsale <martin(at)emepe3(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: seqscan instead of index scan |
Date: | 2004-08-30 18:02:27 |
Message-ID: | 20040830180227.GA32520@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Aug 30, 2004 at 14:46:37 -0300,
Martin Sarsale <martin(at)emepe3(dot)net> wrote:
> Dear all:
>
> Im having a weird problem here. I have a table w/ ~180.000 rows and I
> want to select those where c > 0 or d > 0 (there only a few of those on
> the table)
> I indexed columns c and d (separately) but this query used the slow
> seqscan instead of the index scan:
Postgres doesn't 'or' bitmaps derived from two indexes. You might have more
luck using a combined index.
>
> select * from t where c<>0 or d<>0;
>
> After playing some time, I noticed that if I change the "or" for an
> "and", pg used the fast index scan (but the query w/ 'and' was not what
> I as looking for).
>
> Then, I thought I could do the following:
> Creating an index with the expression (c+d) and selecting the rows where
> c+d > 0:
> select * from t where c + d <> 0;
>
> Again, this used a seqscan. Asking in #postgresql in freenode, somebody
> told me to try to disable seqscan (set enable_seqscan false) and
> suprisingly, Pg started using the index scan and it was -fast-.
>
> Now: I've no idea why it chooses to use a seq scan instead of the index
> scan (yes, I've just vacuum analyzed the table before running the
> query).
>
> Some more info:
> c and d are both bigint. I've tried the queries casting the constant (0)
> to bigint but nothing changed.
>
> Im using debian's pg 7.4.1-2.
>
>
> Thanks in advance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2004-08-30 18:06:48 | Re: seqscan instead of index scan |
Previous Message | Martin Sarsale | 2004-08-30 17:46:37 | seqscan instead of index scan |