Re: seqscan instead of index scan
От | Bruno Wolff III |
---|---|
Тема | Re: seqscan instead of index scan |
Дата | |
Msg-id | 20040830180227.GA32520@wolff.to обсуждение исходный текст |
Ответ на | seqscan instead of index scan (Martin Sarsale <martin@emepe3.net>) |
Ответы |
Re: seqscan instead of index scan
|
Список | pgsql-performance |
On Mon, Aug 30, 2004 at 14:46:37 -0300, Martin Sarsale <martin@emepe3.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 >
В списке pgsql-performance по дате отправления: