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
