On Fri, Aug 23, 2024 at 2:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
That's a fair concern.
> 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.
If just setting disabled_nodes to a value larger than one works, I'd
be inclined to not do anything here at all, except possibly document
that you can do that. Otherwise, we should probably change the code
somehow.
I find both of your proposed solutions above to be pretty inelegant,
and I think if this problem occurred with a core AM, I'd push for an
API break rather than accept the ugliness. "This path is not valid
because the AM cannot support it", "this path is crazy expensive", and
"the user told us not to do it this way" are three different things,
and signalling two or more of them in the same way muddies the water
in a way that I don't like. API breaks aren't free, though, so I
certainly understand why you're not very keen to introduce one where
it can reasonably be avoided.
--
Robert Haas
EDB: http://www.enterprisedb.com
