| From: | "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: The planner chooses seqscan+sort when there is an |
| Date: | 2006-05-03 18:45:25 |
| Message-ID: | 20060503184525.GA14628@webserv.wug-glas.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
am 03.05.2006, um 20:20:55 +0200 mailte Florian G. Pflug folgendes:
> >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.
Yepp, it is much cheaper to read the table seq and order later.
Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sven Willenberger | 2006-05-03 18:52:57 | Re: out of memory for query result |
| Previous Message | Geoffrey | 2006-05-03 18:44:03 | How does an application recognize the death of the postmaster |