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
