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: Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-02T18:37:25Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> What happens right now is:

> - If you set enable_indexscan=false, then disable_cost is added to the
> cost of index scan paths and the cost of index-only scan paths.

> - If you set enable_indexonlyscan=false, then index-only scan paths
> are not generated at all.

Hm.  The first part of that seems pretty weird to me --- why don't
we simply not generate the paths at all?  There is no case AFAIR
where that would prevent us from generating a valid plan.

(I do seem to recall that index-only paths are built on top of regular
index paths, so that there might be implementation issues with trying
to build the former and not the latter.  But you've probably looked
at that far more recently than I.)

			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.