| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
| Cc: | "John D(dot) Burger" <john(at)mitre(dot)org>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: The planner chooses seqscan+sort when there is an |
| Date: | 2006-05-03 16:44:50 |
| Message-ID: | 20060503164450.GD27354@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, May 03, 2006 at 06:42:00PM +0200, Csaba Nagy wrote:
> OK, maybe that's the point... the "cost bust" given to the sequential
> scan by enable_seqscan=off is not enough in this case to exceed the cost
> of the index scan ? The table is quite big, might be possible. I still
> wonder why would be seqscan+sort faster than index scan... the sort will
> for sure have to write to disk too given the size of the table...
Have you tuned the values of effective_cache_size and random_page_cost?
These have significant effects on index scans.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sven Willenberger | 2006-05-03 16:53:31 | Re: out of memory for query result |
| Previous Message | Csaba Nagy | 2006-05-03 16:42:00 | Re: The planner chooses seqscan+sort when there is an |