Horton

Re: On disable_cost

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-02T17:54:02Z
Lists: pgsql-hackers 
On Tue, Jul 2, 2024 at 1:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> FWIW, I disagree completely.  I think it's entirely natural to
> consider bitmap index scans to be a subset of index scans, so that
> enable_indexscan should affect both.  I admit that the current set
> of GUCs doesn't let you force a bitmap scan over a plain one, but
> I can't recall many people complaining about that.  I don't follow
> the argument that this definition is somehow unmaintainable, either.

Well... but that's not what the GUC does either. Not now, and not with
the patch.

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.

Bitmap scans are controlled by enable_bitmapscan.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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.