Re: Unexpected sequential scan on an indexed column

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unexpected sequential scan on an indexed column
Дата
Msg-id 25680.1258328036@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Unexpected sequential scan on an indexed column  (Eddy Escardo-Raffo <eescardo@kikini.com>)
Ответы Re: Unexpected sequential scan on an indexed column  (Eddy Escardo-Raffo <eescardo@kikini.com>)
Список pgsql-performance
Eddy Escardo-Raffo <eescardo@kikini.com> writes:
> The table used in this query is called "users", and it has columns "userid"
> (primary key) and "location".
> The "location" column is indexed.
> The users table has 1 million rows, and all rows have integer typed value
> '-1' for  "location" column, except for 2 rows that have the integer value
> '76543'.

Oh, after poking at it a bit more, I realize the problem: the planner
doesn't want to use an indexscan because it assumes there's a
significant probability that the search will be for -1 (in which case
the indexscan would be slower than a seqscan, as indeed your results
prove).  Even though it could know in this particular case that the
comparison value isn't -1, I doubt that teaching it that would help your
real queries where it will probably be impossible to determine the
comparison values in advance.

I would suggest considering using NULL rather than inventing a dummy
value for unknown locations.  The estimation heuristics will play a
lot nicer with that choice.

            regards, tom lane

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

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