Re: Table AM Interface Enhancements

On 31/3/2024 00:33, Alexander Korotkov wrote:
> I think the way forward might be to introduce the new API, which would
> isolate executor details from table AM. We may introduce a new data
> structure InsertWithArbiterContext which would contain EState and a
> set of callbacks which would avoid table AM from calling the executor
> directly. That should be our goal for pg18. Now, this is too close
> to FF to design a new API.
I'm a bit late, but have you ever considered adding some sort of index
probing routine to the AM interface for estimation purposes?
I am working out the problem when we have dubious estimations. For
example, we don't have MCV or do not fit MCV statistics for equality of
multiple clauses, or we detected that the constant value is out of the
histogram range. In such cases (especially for [parameterized] JOINs),
the optimizer could have a chance to probe the index and avoid huge
underestimation. This makes sense, especially for multicolumn
filters/clauses.
Having a probing AM method, we may invent something for this challenge.

--
regards,
Andrei Lepikhov
Postgres Professional