Re: Seqscan rather than Index

От: Steinar H. Gunderson
Тема: Re: Seqscan rather than Index
Дата: ,
Msg-id: 20041217235548.GD16149@uio.no
(см: обсуждение, исходный текст)
Ответ на: Re: Seqscan rather than Index  (Frank Wiles)
Список: pgsql-performance

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

Seqscan rather than Index  (Jon Anderson, )
 Re: Seqscan rather than Index  (Tom Lane, )
 Re: Seqscan rather than Index  (David Brown, )
  Re: Seqscan rather than Index  (Richard Huxton, )
   Re: Seqscan rather than Index  (Greg Stark, )
    Re: Seqscan rather than Index  (Tom Lane, )
     Re: Seqscan rather than Index  (Greg Stark, )
      Re: Seqscan rather than Index  (Tom Lane, )
    Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
     Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
      Re: Seqscan rather than Index  (Frank Wiles, )
       Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
       Re: Seqscan rather than Index  (Tom Lane, )
        Re: Seqscan rather than Index  (Frank Wiles, )
     Re: Seqscan rather than Index  (Bruno Wolff III, )
      Re: Seqscan rather than Index  ("Steinar H. Gunderson", )

On Fri, Dec 17, 2004 at 05:02:29PM -0600, Frank Wiles wrote:
>   It depends more on your disk IO than the processor.  Counting isn't
>   processor intensive, but reading through the entire table on disk
>   is.  I've also seen a huge difference between select count(*) and
>   select count(1) in older versions, haven't tried it on a recent
>   version however.

Like I said, all in cache, so no disk IO. count(*) and count(1) give me
identical results. (BTW, I don't think this is a count problem, it's a
"sequential scan" problem -- I'm just trying to find out if this is natural
or not, ie. if this is just something I have to expect in a relational
database, even with no I/O.)

/* Steinar */
--
Homepage: http://www.sesse.net/


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

От: Tom Lane
Дата:
Сообщение: Re: Seqscan rather than Index
От: John A Meinel
Дата:
Сообщение: Re: Improve performance of query