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-02T19:28:38Z
Lists: pgsql-hackers 
On Tue, Jul 2, 2024 at 2:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Well, yeah.

What the patch does is: if you set either enable_indexscan=false or
enable_indexonlyscan=false, then the corresponding path type is not
generated, and the other is unaffected. To me, that seems like the
logical way to clean this up.

One could argue for other things, of course. And maybe those other
things are fine, if they're properly justified and documented.

-- 
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.