Re: index / sequential scan problem

От: Tom Lane
Тема: Re: index / sequential scan problem
Дата: ,
Msg-id: 5494.1058464980@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: index / sequential scan problem  (Paul Thomas)
Список: 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, )

Paul Thomas <> writes:
> 2) enable_seqscan = false
>> Seq Scan on notiz_objekt a  (cost=100000000.00..100111719.36 rows=15561
>> width=12) (actual time=0.25..535.75 rows=31122 loops=1)

> I've just noticed this. Something is not right here. Look at the crazy
> cost estimation for the second query.

No, that's exactly what it's supposed to do.  enable_seqscan cannot
simply suppress generation of a seqscan plan (because that might be
the only way to do the query, if there's no applicable index).  So it
generates the plan, but sticks a large penalty into the cost estimate
to keep the planner from choosing that alternative if there is any
other.  The "100000000.00" is that artificial penalty.

We could probably hide this implementation detail from you if we tried
hard enough, but it hasn't bothered anyone enough to try.

            regards, tom lane


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

От: Josh Berkus
Дата:
Сообщение: Table clustering -- useful, or not?
От: Robert Creager
Дата:
Сообщение: Re: Hardware performance