Re: More Performance

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

In response to

Responses

Browse pgsql-general by date

  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))

Browse pgsql-hackers by date

  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))