From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: [BUGS] BUG #11500: PRIMARY KEY index not being used |
Date: | 2025-10-05 00:34:28 |
Message-ID: | CAApHDvpVcN=yKT2Jg96GotHyP2_nB4M6mWiLXqAqrvvXan-y2g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sun, 5 Oct 2025 at 06:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Index Scan using orders_wait_event_idx on orders
> (cost=0.54..94812.85 rows=85043 width=1223) (actual
> time=0.166..7199.020 rows=84535 loops=1)
> That's a pretty darn accurate rowcount estimate, so "out of date
> stats" doesn't seem to be the problem. I don't think it could
> possibly have believed that scanning the pkey index would fetch that
> many rows, or cost that much. So why didn't it pick that index?
> No way to tell from this amount of info, but I'm suspecting a
> moving part that we don't know about.
>
> (Hmmm ... why is there not a "Filter: (order_id = $1)" line here?)
Marko did mention:
On Sat, 4 Oct 2025 at 15:40, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> That was an after-the-fact demonstration of how expensive gambling on the index can be.
I assumed since the EXPLAIN didn't match the query that the EXPLAIN
output was fabricated afterwards from the server without the
"order_id" qual to try to illustrate the index that was used and the
row numbers that index had to visit. It would be good to get
confirmation of that from Marko. Otherwise, indeed, something very
strange is going on if the planner produced the above plan for the
given query.
David
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2025-10-05 02:29:34 | BUG #19073: there are meaningless code in _SPI_execute_plan() when canSetTag is true |
Previous Message | Bernice Southey | 2025-10-04 20:02:15 | Re: BUG #19072: New-style SQL language function referencing a temp table behaves oddly |