Re: On disable_cost

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Aug 23, 2024 at 2:18 PM Heikki Linnakangas <hlinnaka(at)iki(dot)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.

If we're going to do this, I'd prefer a solution that doesn't force
API changes onto the vast majority of index AMs that don't have a
problem here.

One way could be to formalize the hack we were just discussing:
"To refuse a proposed path, amcostestimate can set the path's
disabled_nodes value to anything larger than 1". I suspect that
that would actually be sufficient, since the path would then lose
to the seqscan path in add_path even if that were disabled; but
we could put in a hack to prevent it from getting add_path'd at all.

Another way could be to bless what hnsw is already doing:
"To refuse a proposed path, amcostestimate can return an
indexTotalCost of DBL_MAX" (or maybe insisting on +Inf would
be better). That would still require changes comparable to
what you specify above, but only in the core-code call path
not in every AM.

regards, tom lane