Horton

Re: On disable_cost

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, David Rowley <dgrowleyml@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, andrew@ankane.org
Date: 2024-08-23T17:42:53Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Aug 23, 2024 at 1:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It looks like amcostestimate could change the path's disabled_nodes
>> count, since that's set up before invoking amcostestimate.  I guess
>> it could be set to INT_MAX to have a comparable solution to before.

> It's probably better to add a more modest value, to avoid overflow.
> You could add a million or so and be far away from overflow while
> presumably still being more disabled than any other path.

But that'd only matter if the path survived its first add_path
tournament, which it shouldn't.  If it does then you're at risk
of the same run-time failure reported here.

(Having said that, you're likely right that "a million or so"
would be a safer choice, since it doesn't require the assumption
that the path fails instantly.)

			regards, tom lane

Commits

  1. Doc: add detail about EXPLAIN's "Disabled" property

  2. Adjust EXPLAIN's output for disabled nodes

  3. Fix order of parameters in a cost_sort call

  4. Show number of disabled nodes in EXPLAIN ANALYZE output.

  5. Treat number of disabled nodes in a path as a separate cost metric.

  6. Remove grotty use of disable_cost for TID scan plans.