Horton

Re: Table AM Interface Enhancements

Andrei Lepikhov <a.lepikhov@postgrespro.ru>

View thread View on postgr.es
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Japin Li <japinli@hotmail.com>, Mark Dilger <mark.dilger@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-04-01T07:00:42Z
Lists: 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

Commits

  1. Remove extra comment at TableAmRoutine.scan_analyze_next_block

  2. revert: Generalize relation analyze in table AM interface

  3. Revert: Allow table AM to store complex data structures in rd_amcache

  4. Revert: Allow table AM tuple_insert() method to return the different slot

  5. Revert: Allow locking updated tuples in tuple_update() and tuple_delete()

  6. Revert: Let table AM insertion methods control index insertion

  7. Revert: Custom reloptions for table AM

  8. Provide a way block-level table AMs could re-use acquire_sample_rows()

  9. Custom reloptions for table AM

  10. Use streaming I/O in ANALYZE.

  11. Revert "Custom reloptions for table AM"

  12. Let table AM insertion methods control index insertion

  13. Generalize relation analyze in table AM interface

  14. Improve error message for tts_(virtual|minimal)_is_current_xact_tuple

  15. Add comments on some MinimalTupleSlots methods usage

  16. Add TupleTableSlotOps.is_current_xact_tuple() method

  17. Allow table AM tuple_insert() method to return the different slot

  18. Allow table AM to store complex data structures in rd_amcache