От: Michael Fuhr
Тема: Re: Sort and index
Дата: ,
Msg-id: 20050418171013.GA34421@winnie.fuhr.org
(см: обсуждение, исходный текст)
Ответ на: Re: Sort and index  ("Dave Held")
Ответы: Re: Sort and index  (Andrei Gaspar)
Список: pgsql-performance

Скрыть дерево обсуждения

Sort and index  (Andrei Gaspar, )
 Re: Sort and index  ("Dave Held", )
  Re: Sort and index  (Andrei Gaspar, )
  Re: Sort and index  (Michael Fuhr, )
   Re: Sort and index  (Andrei Gaspar, )
  Re: Sort and index  ("Jim C. Nasby", )
   Re: Sort and index  (Tom Lane, )
    Re: Sort and index  ("Jim C. Nasby", )
     Re: Sort and index  ("Jim C. Nasby", )
      Re: Sort and index  (Tom Lane, )
       Re: Sort and index  ("Jim C. Nasby", )
        Re: Sort and index  (Tom Lane, )
         Re: Sort and index  ("Jim C. Nasby", )
          Re: Sort and index  (Manfred Koizar, )
           Re: Sort and index  ("Jim C. Nasby", )
            Re: Sort and index  (Manfred Koizar, )
             Re: Sort and index  ("Jim C. Nasby", )

On Mon, Apr 18, 2005 at 10:44:43AM -0500, Dave Held wrote:
> >
> > I thought that an index can be used for sorting.
> > I'm a little confused about the following result:
> >
> > create index OperationsName on Operations(cOperationName);
> > explain SELECT * FROM Operations ORDER BY cOperationName;
> >                               QUERY PLAN
> > --------------------------------------------------------------
> > ---------
> >  Sort  (cost=185.37..189.20 rows=1532 width=498)
> >    Sort Key: coperationname
> >    ->  Seq Scan on operations  (cost=0.00..104.32 rows=1532 width=498)
> > (3 rows)
> >
> > Is this supposed to be so?
>
> Since you are fetching the entire table, you are touching all the rows.
> If the query were to fetch the rows in index order, it would be seeking
> all over the table's tracks.  By fetching in sequence order, it has a
> much better chance of fetching rows in a way that minimizes head seeks.
> Since disk I/O is generally 10-100x slower than RAM, the in-memory sort
> can be surprisingly slow and still beat indexed disk access.  Of course,
> this is only true if the table can fit and be sorted entirely in memory
> (which, with 1500 rows, probably can).

Out of curiosity, what are the results of the following queries?
(Queries run twice to make sure time differences aren't due to
caching.)

SET enable_seqscan TO on;
SET enable_indexscan TO off;
EXPLAIN ANALYZE SELECT * FROM Operations ORDER BY cOperationName;
EXPLAIN ANALYZE SELECT * FROM Operations ORDER BY cOperationName;

SET enable_seqscan TO off;
SET enable_indexscan TO on;
EXPLAIN ANALYZE SELECT * FROM Operations ORDER BY cOperationName;
EXPLAIN ANALYZE SELECT * FROM Operations ORDER BY cOperationName;

SELECT version();

With 1500 rows of random data, I consistently see better performance
with an index scan (about twice as fast as a sequence scan), and
the planner uses an index scan if it has a choice (i.e., when
enable_seqscan and enable_indexscan are both on).  But my test case
and postgresql.conf settings might be different enough from yours
to account for different behavior.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/


В списке pgsql-performance по дате сообщения:

От: Alvaro Herrera
Дата:
Сообщение: Re: How to improve db performance with $7K?
От: Matthew Nuzum
Дата:
Сообщение: Re: How to improve db performance with $7K?