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