Re: More Performance

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: More Performance
Дата
Msg-id 200005202043.QAA29734@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: More Performance  ("Matthias Urlichs" <smurf@noris.net>)
Ответы Re: More Performance  (Tom Lane <tgl@sss.pgh.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.

We can't read data from the index.  It would be nice if we could, but we
can't.  I think we believe that there are very few cases where this
would be win.  Usually you need non-indexed data too.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


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

Предыдущее
От: "Matthias Urlichs"
Дата:
Сообщение: Re: More Performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Performance (was: The New Slashdot Setup (includes MySql server))