From: | "Matthias Urlichs" <smurf(at)noris(dot)net> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Matthias Urlichs <smurf(at)noris(dot)net>, Mike Mascari <mascarm(at)mascari(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: More Performance |
Date: | 2000-05-20 20:30:21 |
Message-ID: | 20000520223021.F11220@noris.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Hi,
Bruce Momjian:
> >
> > test=# explain select id from bench1 order by id;
> > Sort (cost=38259.21..38259.21 rows=300000 width=4)
> > -> Seq Scan on bench1 (cost=0.00..6093.00 rows=300000 width=4)
> >
> The heap is unordered, meaning a sequential scan and order by is usually
> faster than an index walk unless there is a restrictive WHERE clause.
>
What heap? The index is a b-tree in this case. Thus you should be able
to walk it and get the sorted result without ever touching the data
file.
Whether that makes sense with the current structure of the PostgreSQL
backend is a different question, of course. Certain othr databases
(no, not just MySQL ;-) are capable of doing that optimization, however.
--
Matthias Urlichs | noris network GmbH | smurf(at)noris(dot)de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
The difference between a rich man and a poor man is this -- the former
eats when he pleases, the latter when he can get it.
-- Sir Walter Raleigh
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Urlichs | 2000-05-20 20:40:43 | Re: More Performance |
Previous Message | Matthias Urlichs | 2000-05-20 20:26:40 | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Urlichs | 2000-05-20 20:40:43 | Re: More Performance |
Previous Message | Matthias Urlichs | 2000-05-20 20:26:40 | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |