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: David Rowley <dgrowleyml@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-08-02T16:51:12Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Aug 2, 2024 at 9:13 AM David Rowley <dgrowleyml@gmail.com> wrote:
>> ... That way you maintain the
>> existing behaviour of not optimising for disabled node types and don't
>> risk plan changes if the final cost comes out cheaper than the initial
>> cost.

> All three initial_cost_XXX functions have a comment that says "This
> must quickly produce lower-bound estimates of the path's startup and
> total costs," i.e. the final cost should never be cheaper. I'm pretty
> sure that it was the design intention here that no path ever gets
> rejected at the initial cost stage that would have been accepted at
> the final cost stage.

That absolutely is the expectation, and we'd better be careful not
to break it.

			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.