Re: More Performance

Поиск
Список
Период
Сортировка
От Matthias Urlichs
Тема Re: More Performance
Дата
Msg-id 20000520223021.F11220@noris.de
обсуждение исходный текст
Ответ на Re: More Performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: More Performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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@noris.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: MySQL's "crashme" (was Re: Performance)
Следующее
От: "Matthias Urlichs"
Дата:
Сообщение: Re: More Performance