ScanKeys passed to table_beginscan in SeqNext
Hello PG Devs,
For an extension I am working on. I want to create a new storage
access method. To do this, I would like/need to get scan_keys passed to
table_beginscan in SeqNext. For reference, the comments in SeqRecheck
/*
* Note that unlike IndexScan, SeqScan never use keys in heap_beginscan
* (and this is very bad) - so, here we do not check are keys ok or not.
*/
Is there a plan to have scan keys passed to table_beginscan in SeqNext? and
if not, is there a reason why? I know the heap access method has support
for it.
I am trying to build a key/value access method for a very specific use case
and this seems to be my best option. I don't want to use an index because
part of the goal of adding this access method to the project is to reduce
write amplification of updates, and to make that work with an index would
be much more sophisticated and I feel would be more likely to break.
Thank You,
Josh Innis
Josh Innis <joshinnis@gmail.com> writes:
Is there a plan to have scan keys passed to table_beginscan in SeqNext? and
if not, is there a reason why? I know the heap access method has support
for it.
AFAIK the only part of the system that relies on HeapKeyTest to do
anything useful is the catcache, which has cases in which it has to do
a seqscan of some catalog because the infrastructure for indexscans
might not be alive yet (cf. IndexScanOK). If HeapKeyTest didn't work
then we'd have to put equivalent code in systable_getnext or somewhere
nearby.
However, it doesn't follow that making use of that code in general SQL
queries is worth our trouble. We'd have to build out support in the
planner and the executor, and we'd have to define which operators
are expected to work in this context (there's no operator classes
associated with heaps...), and it's really unclear that any benefit
would ensue. I don't see a reason to think that executing qual
clauses via HeapKeyTest would be very much faster than executing them
as regular quals. Given all the optimization effort that's gone into
the general expression-evaluation code, it could easily be slower.
If you have an access method that is capable of usefully optimizing
qual checks, perhaps you should be thinking about it as a kind of
index access method rather than a kind of heap. Alternatively,
you could build CustomScan plan nodes and do whatever you want
inside those.
Or in short: there are reasons why nobody's followed up on that
decades-old comment.
regards, tom lane