Re: index / sequential scan problem

От: Fabian Kreitner
Тема: Re: index / sequential scan problem
Дата: ,
Msg-id: 5.1.0.14.0.20030717131157.03957fa0@195.145.148.245
(см: обсуждение, исходный текст)
Ответ на: Re: index / sequential scan problem  (Paul Thomas)
Ответы: Re: index / sequential scan problem  (Paul Thomas)
Re: index / sequential scan problem  (Tom Lane)
Список: pgsql-performance

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

index / sequential scan problem  (Fabian Kreitner, )
 Re: index / sequential scan problem  ("Shridhar Daithankar", )
  Re: index / sequential scan problem  (Fabian Kreitner, )
   Re: index / sequential scan problem  ("Shridhar Daithankar", )
 Re: index / sequential scan problem  (Paul Thomas, )
  Re: index / sequential scan problem  (Fabian Kreitner, )
   Re: index / sequential scan problem  (Paul Thomas, )
    Re: index / sequential scan problem  (Fabian Kreitner, )
     Re: index / sequential scan problem  ("Shridhar Daithankar", )
     Re: index / sequential scan problem  (Jord Tanner, )
     Re: index / sequential scan problem  (Paul Thomas, )
      Re: index / sequential scan problem  (Tom Lane, )
   Re: index / sequential scan problem  (Tom Lane, )
    Re: index / sequential scan problem  (Fabian Kreitner, )
     Re: index / sequential scan problem  (Fabian Kreitner, )
      Re: index / sequential scan problem  (Dennis Björklund, )
       Re: index / sequential scan problem  (Tom Lane, )
        Re: index / sequential scan problem  ("scott.marlowe", )
        Re: index / sequential scan problem  (Dennis Björklund, )

At 12:12 17.07.2003, you wrote:

>On 17/07/2003 10:01 Fabian Kreitner wrote:
>
>Hi Fabian,
>
>When you are doing these kinds of tests, you need to be aware that the
>kernel may have most of your data cached after the first query and this
>may be why the second query appears to run faster.

I thought of this too, but executions times wont change with repeating /
alternating these two tests.

>Also don't be worried if the planner chooses a seq scan for small tables
>as the whole table can often be bought into memory with one IO whereas
>reading the index then the table would be 2 IOs. HTH

That is what I read too and is why Im confused that the index is indeed
executing faster. Can this be a problem with the hardware and/or postgress
installation?

Thanks,
   Fabian



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

От: Jord Tanner
Дата:
Сообщение: Re: Hardware performance
От: Tom Lane
Дата:
Сообщение: Re: index / sequential scan problem