From: | "Florian G(dot) Pflug" <fgp(at)phlo(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 18:20:55 |
Message-ID: | 4458F487.80404@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Csaba Nagy wrote:
>> Docs say:
>>
>>> Enables or disables the query planner's use of sequential scan plan
>>> types. It's not possible to suppress sequential scans entirely, but
>>> turning this variable off discourages the planner from using one if
>>> there are other methods available.
>> Note the second sentence. Again, I think it will have to scan the
>> whole table anyway, because that's what you've asked for, and given
>> that, enable_seqscan=off doesn't apply.
>
> 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...
When using an indexscan, postgres will read the actual rows in
index-order, rathen then in the order they appear on-disk.
For 200 million rows this means doing at least 200 million
disk seeks. Assuming that each seek takes just 1ms, thats
still amount to 200.000 seconds.
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-03 18:34:08 | Re: The planner chooses seqscan+sort when there is an |
Previous Message | Joao Miguel Ferreira | 2006-05-03 18:19:47 | Re: database size grows (even after vacuum (full and |