Re: Unexpected sequential scan on an indexed column

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unexpected sequential scan on an indexed column
Дата
Msg-id 28141.1258334599@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unexpected sequential scan on an indexed column  (Eddy Escardo-Raffo <eescardo@kikini.com>)
Список pgsql-performance
Eddy Escardo-Raffo <eescardo@kikini.com> writes:
> For C, the planner estimated 10 thousand rows. For D, the planner estimated
> 100 thousand rows, yet for E the planner estimated only 1 row, which is the
> closest to reality. So, is there any way to specify a query that has a
> SUB-SELECT that returns a small set of values so that the planner treats it
> similar to how it treats statement E, or does statement E get its additional
> edge precisely from the fact that the restriction is defined by integer
> literals?

Currently there is no attempt to look at the exact contents of a VALUES
construct for planning purposes.  For the examples you're showing it
seems like the IN (list) notation is more compact and more widely used,
so improving the VALUES alternative doesn't seem that exciting.

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Eddy Escardo-Raffo
Дата:
Сообщение: Re: Unexpected sequential scan on an indexed column
Следующее
От: Laurent Laborde
Дата:
Сообщение: Re: limiting performance impact of wal archiving.