Re: Seq scan instead of index scan querying single row from primary key on large table

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Seq scan instead of index scan querying single row from primary key on large table
Дата
Msg-id 3783591.1721327902@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Seq scan instead of index scan querying single row from primary key on large table  (James Coleman <jtc331@gmail.com>)
Ответы Re: Seq scan instead of index scan querying single row from primary key on large table
Список pgsql-hackers
James Coleman <jtc331@gmail.com> writes:
> The plan generated by the planner changed suddenly one morning this
> week, and in a very surprising way: the innermost scan (of "objects")
> started choosing a seq scan, despite the cost from that node being
> very high and an index scan being possible

That looks weird to me too, but given the number of tables involved
I wonder what you have join_collapse_limit/from_collapse_limit set
to.  If those are smaller than the query's relation count it could
be that this is an artifact of optimization of a join subproblem.
However, if it's the very same query you've been generating all along,
this theory doesn't really explain the sudden change of plan choice.

Also, even granting the bad-peephole-optimization theory, it seems
like the best path for the objects table alone would still have been
the index scan, so I'm confused too.  What nondefault planner settings
have you got?  ("EXPLAIN (SETTINGS)" would help with answering that
accurately.)

Are you really sure nothing changed about what the ORM is emitting?

            regards, tom lane



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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: improve performance of pg_dump with many sequences
Следующее
От: Paul Jungwirth
Дата:
Сообщение: Re: SQL:2011 application time