From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Francisco Reyes <lists(at)natserv(dot)com> |
Cc: | John Meinel <john(at)johnmeinel(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: why my query is not using index?? |
Date: | 2004-10-12 05:26:53 |
Message-ID: | 28283.1097558813@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Francisco Reyes <lists(at)natserv(dot)com> writes:
> With explain analyze I have with sequential scan on
> Sort (cost=382.01..382.15 rows=56 width=196)
> (actual time=64.346..64.469 rows=24 loops=1)
> And with seqscan off
> Sort (cost=490.82..490.96 rows=56 width=196)
> (actual time=56.668..56.789 rows=24 loops=1)
> So I guess that for this particular query I am better off setting the
> seqscan off.
For that kind of margin, you'd be a fool to do any such thing.
You might want to look at making some adjustment to random_page_cost
to bring the estimated costs in line with reality (though I'd counsel
taking more than one example into account while you tweak it). But
setting seqscan off as a production setting is just a recipe for
shooting yourself in the foot.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-12 05:45:15 | Re: Normal case or bad query plan? |
Previous Message | Gabriele Bartolini | 2004-10-12 05:26:12 | Re: Normal case or bad query plan? |