Hi hackers,
I'm developing an index AM for a specific user defined type. Details
about LIMIT clause can lead to different strategy during scan. So
"SELECT * FROM tbl ORDER BY col LIMIT 5" will have a different
code path to "SELECT * FROM tbl ORDER BY col LIMIT 500".
It's still the same IndexScan.
In planning phase, we have this via amcostestimate. But I don't
see a proper way in ambeginscan/amrescan/amgettuple. For
example,
ambeginscan_function: we have indexRelation, nkeys and norderbys.
amrescan_function: we have the IndexScanDesc built by beginscan,
and detailed info about the scan keys.
amgettuple_function: we have IndexScanDesc, and scan direction.
Maybe I miss some API please point out, thanks.
In FDW API, BeginForeignScan has ForeignScanState which
includes the whole plan. It's possible to find LIMIT clause.
So I propose adding a ScanState pointer to IndexScanDesc. In
IndexNext() populate this in IndexScanDesc after ambeginscan.
Then amrescan/amgettuple can adjust it's strategy with information
about LIMIT cluase, or more generally the whole plan tree. This
will make AM scan API on par with FDW API in my opinion. This
approach should be compatible with existing extensions if we place
the newly added pointer at the end of IndexScanDesc.
Another approach is adding a new API to IndexAmRoutine and
give the extension a way to access plan information. But this
doesn't seems to provide more benefits compare to the above
approach.
Thoughts?
Best regards,
Peifeng Qiu