Horton

Re: On disable_cost

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, andrew@ankane.org
Date: 2024-08-23T18:36:09Z
Lists: pgsql-hackers 
On Fri, Aug 23, 2024 at 2:18 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> It would seem useful for an index AM to be able to say "nope, I can't do
> this". I don't remember how exactly this stuff works, but I'm surprised
> it doesn't already exist.

Yeah, I think so, too. While this particular problem is due to a
problem with an out-of-core AM that may be doing some slightly
questionable things, there's not really any reason why we couldn't
have similar problems in core for some other reason. For example, we
could change amcostestimate's signature so that an extension can
return true or false, with false meaning that the path can't be
supported. We could then change cost_index so that it can also return
true or false, and then change create_index_path so it has the option
to return NULL. Callers of create_index_path could then be adjusted
not to call add_path when NULL is returned.

There might be a more elegant way to do it with more refactoring, but
the above seems good enough.

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