Re: Table AM Interface Enhancements - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Table AM Interface Enhancements
Date
Msg-id cf38c55c-113a-41e9-a075-ab0df94724df@postgrespro.ru
Whole thread Raw
In response to Re: Table AM Interface Enhancements  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Table AM Interface Enhancements
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Bertrand Drouvot
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation