agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: manuelreyesbravo@gmail.com
Subject: BUG #19639: EXPLAIN (FORMAT JSON) emits a 309-digit cost value, and the node still reports "Disabled": false
Date: Sun, 23 Aug 2026 23:46:57 +0000
Message-ID: <19639-9b1c9624a6034702@postgresql.org> (raw)
The following bug has been logged on the website:
Bug reference: 19639
Logged by: Manuel Reyes Bravo
Email address: manuelreyesbravo@gmail.com
PostgreSQL version: 19beta3
Operating system: Fedora 44, Linux 7.1.8, gcc 16.1.1, PostgreSQL bui
Description:
Note up front: reproducing this needs a third-party index access method, but
what I am reporting is the EXPLAIN output itself. Whatever the origin of the
cost value, EXPLAIN (FORMAT JSON) emitting a 309-digit numeric literal
breaks
JSON consumers, and that part is in core. See "On attribution" at the end
for
what I did and did not verify.
On 19beta3, EXPLAIN (FORMAT JSON) can emit a cost of DBL_MAX, rendered as a
309-digit number. serde_json rejects it with "number out of range", and I
would
expect most plan-analysis tooling to have the same problem, since there is
no
way for a client to consume it other than parsing the number as text.
There is a second, separate oddity in the same output: the node carries
"Disabled": false while having that saturated cost. On 18.6 the same query
gets an ordinary cost and the disabled node is marked as disabled, which is
what the disabled-nodes mechanism exists for.
Reproducer
----------
Using pgvectorscale 0.9.0 ("diskann") with pgvector 0.8.6:
CREATE EXTENSION vector;
CREATE EXTENSION vectorscale;
CREATE TABLE t_quant (
id SERIAL PRIMARY KEY,
embedding vector(3),
labels SMALLINT[]
);
CREATE INDEX idx_quant ON t_quant USING diskann (embedding, labels);
INSERT INTO t_quant (embedding, labels) VALUES
('[1,2,3]', '{1,2}'), ('[4,5,6]', '{1,3}'), ('[7,8,9]', '{2,3}');
SET enable_seqscan = 0;
EXPLAIN (FORMAT JSON)
SELECT * FROM t_quant
WHERE labels && '{1}'
ORDER BY labels, embedding <=> '[0,0,0]';
Ordering by labels first is the point: the index cannot satisfy that
ordering,
so with enable_seqscan off the only remaining plan is a penalized one.
19beta3:
"Node Type": "Sort"
"Total Cost": 179769313486231570814527423731704356798... (309 digits)
"Disabled": false
"Node Type": "Index Scan"
"Total Cost": 179769313486231570814527423731704356798... (309 digits)
"Disabled": false
18.6 (same extension, same schema, same query):
"Node Type": "Sort"
"Total Cost": 20.64
"Disabled": false
"Node Type": "Seq Scan"
"Total Cost": 20.63
"Disabled": true
The text format shows the same value, with the cost running off the line.
Two issues, I believe
---------------------
1. Regardless of how the cost became that large, EXPLAIN (FORMAT JSON)
producing a 309-digit numeric literal is a problem in itself. JSON
consumers
are not prepared for it.
2. "Disabled": false together with a saturated cost is self-contradictory.
Since the disabled-nodes mechanism was introduced precisely so that
disabling a node no longer required inflating its cost, seeing both
suggests
something is not going through that mechanism.
On attribution
--------------
What I measured: 19beta3 emits this and 18.6 does not, with identical
extension
code, schema and query.
What I did not determine: where the value originates. It is possible that
the
AM's amcostestimate returns a very large cost and that 19 propagates it
while
18 never generated that path at all (18 picks a sequential scan instead). So
I
am not claiming the root cause is in core -- but issue 1 seems worth
addressing
either way, and issue 2 looks like a genuine inconsistency in the output.
Versions tested
---------------
PostgreSQL 19beta3, built from source: as shown above
PostgreSQL 18.6, built from source with the same compiler and flags:
normal costs
Happy to dig further if someone points me at the right place to look.
view thread (3+ messages) latest in thread
Message-ID: <19639-9b1c9624a6034702@postgresql.org>
Permalink: ../19639-9b1c9624a6034702@postgresql.org/
Also on: postgresql.org/message-id/19639-9b1c9624a6034702@postgresql.org
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: noreply@postgresql.org, pgsql-bugs@lists.postgresql.org, manuelreyesbravo@gmail.com
Subject: Re: BUG #19639: EXPLAIN (FORMAT JSON) emits a 309-digit cost value, and the node still reports "Disabled": false
In-Reply-To: <19639-9b1c9624a6034702@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox