Re: On disable_cost

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, David Rowley <dgrowleyml(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, andrew(at)ankane(dot)org
Subject: Re: On disable_cost
Date: 2024-08-23 21:33:12
Message-ID: 18df7a4e-59e5-42df-b45a-92b820335200@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/23/24 3:32 PM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I find both of your proposed solutions above to be pretty inelegant,
>
> They are that. If we were working in a green field I'd not propose
> such things ... but we aren't. I believe there are now a fair number
> of out-of-core index AMs, so I'd rather not break all of them if we
> don't have to.

For distribution of index AMs in the wild, it's certainly > 1 now, and
increasing. They're not the easiest extension types to build out, so
it's not as widely distributed as some of the other APIs, but there are
a bunch out there, as well as language-specific libs (e.g. pgrx for
Rust) that offer wrappers around them.

>> 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.
>
> I think it's not that bad, because we can limit the knowledge of this
> hack to the amcostestimate interface, which doesn't really deal in
> "the user told us not to do it this way" at all. That argues against
> my first proposal though (having amcostestimate touch disabled_nodes
> directly). I now think that a reasonable compromise is to say that
> setting indexTotalCost to +Inf signals that "the AM cannot support
> it". That's not conflated too much with the other case, since even a
> crazy-expensive cost estimate surely ought to be finite. We can have
> cost_index untangle that case into a separate failure return so that
> the within-the-core-optimizer APIs remain clean.
>
> While that would require hnsw to make a small code change (return
> +Inf not DBL_MAX), that coding should work in back branches too,
> so they don't even need a version check.

+1 for this approach (I'll do a quick test in my pgvector workspace just
to ensure it gets the same results in the older version).

Jonathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-08-23 21:39:40 Re: [PATCH] Guard `CLOBBER_FREED_MEMORY` & `MEMORY_CONTEXT_CHECKING`
Previous Message Jonathan S. Katz 2024-08-23 21:29:10 Re: On disable_cost