Tom Lane writes:
> I'm not sure what to do about this. I think that things might work
> out better if we redefined the startup cost as "estimated cost to
> retrieve the first tuple", rather than its current very-squishy
> definition as "cost to initialize the scan".
Actually I wanted to raise t
James Coleman writes:
> On Thu, Jul 18, 2024 at 2:38 PM Tom Lane wrote:
>> Are you really sure nothing changed about what the ORM is emitting?
> Yes, aside from the fact that application code didn't change, we
> reproduced the problem by restoring a physical snapshot of the
> database and were a
On Thu, Jul 18, 2024 at 2:38 PM Tom Lane wrote:
>
> James Coleman 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
> > ve
James Coleman 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
Hi all,
I've been optimizing queries for a long time, and I don't think I've
ever seen something more surprising to me than this -- sufficiently so
that I wanted to ask if others thought it implied a bug. It's possible
my mental model for the planner is broken in some significant way, or
that I'm
