Re: index / sequential scan problem

От: Shridhar Daithankar
Тема: Re: index / sequential scan problem
Дата: ,
Msg-id: 3F16E9DB.15319.90FDAD@localhost
(см: обсуждение, исходный текст)
Ответ на: Re: index / sequential scan problem  (Fabian Kreitner)
Список: 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, )

On 17 Jul 2003 at 14:50, Fabian Kreitner wrote:

> At 14:34 17.07.2003, you wrote:
> >I expect you will find that the third query is also a lot faster that the
> >first query.
>
> Im afraid, no.
> Database has been stopped / started right before this.
>
> perg_1097=# set enable_seqscan to true;
> SET VARIABLE
> perg_1097=# EXPLAIN ANALYZE    select  notiz_id, obj_id, obj_typ
> perg_1097-#      from    notiz_objekt a
> perg_1097-#      where not exists

Well, he said query and not the query plan...:-)

While explain analyze is great for judging what is happening, it's not always a
good idea to trust the numbers produced by it. It will probably produce same
number for a SCSI disk machine and for a IDE disk machine, everything else
being equal. Obviously that is not correct.

Only thing you can trust in explain analyze is it's plan. Numbers are based on
heuristic and should be taken as hint only.

Bye
 Shridhar

--
Harrisberger's Fourth Law of the Lab:    Experience is directly proportional to
the amount of equipment ruined.



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

От: Bill Moran
Дата:
Сообщение: Re: Relation of indices to ANALYZE
От: "Magnus Hagander"
Дата:
Сообщение: Re: Hardware performance