Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19639: EXPLAIN (FORMAT JSON) emits a 309-digit cost value,
 and the node still reports "Disabled": false
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: manuelreyesbravo@gmail.com
Reply-To: manuelreyesbravo@gmail.com, pgsql-bugs@lists.postgresql.org
Date: Sun, 23 Aug 2026 23:46:57 +0000
Message-ID: <19639-9b1c9624a6034702@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19639-9b1c9624a6034702%40postgresql.org>
Precedence: bulk

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:       =20

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 =3D 0;
    EXPLAIN (FORMAT JSON)
      SELECT * FROM t_quant
       WHERE labels && '{1}'
       ORDER BY labels, embedding <=3D> '[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.