From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David Wilson" <david(dot)t(dot)wilson(at)gmail(dot)com> |
Cc: | "Alban Hertroys" <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: select distinct and index usage |
Date: | 2008-04-08 02:15:03 |
Message-ID: | 13570.1207620903@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"David Wilson" <david(dot)t(dot)wilson(at)gmail(dot)com> writes:
> It appears to be doing a sequential scan regardless of the set, as if
> it doesn't believe it can use the index for some reason
More likely, it's getting a cost estimate for the indexscan that's so
bad that it even exceeds the 100000000-unit thumb on the scales that's
inserted by enable_seqscan=off.
You could try setting enable_sort=off also, which'd give you another
100000000 worth of thumb on the scales. And if that doesn't help,
reduce random_page_cost to 1 or even less.
What I think you'll find, though, is that once you do force an indexscan
to be picked it'll be slower. Full-table index scans are typically
worse than seqscan+sort, unintuitive though that may sound.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-04-08 02:16:58 | Re: select distinct and index usage |
Previous Message | Markus Wollny | 2008-04-08 02:08:17 | tsvector_update_trigger throws error "column is not of tsvector type" |