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

James Coleman <jtc331(at)gmail(dot)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