Hi, On 2021-06-03 17:52:24 -0700, Jeff Davis wrote: > I agree that would be very conventient for non-heap AMs. There's a very > old commit[3] that says: > > + /* > + * Note that unlike IndexScan, SeqScan never use keys > + * in heap_beginscan (and this is very bad) - so, here > + * we have not check are keys ok or not. > + */ > > and that language has just been carried forward for decades. I wonder > if there's any major reason this hasn't been done yet. Does it just not > improve performance for a heap, or is there some other reason?
It's not actually a good idea in general: - Without substantial refactoring more work is done while holding the content lock on the page. Whereas doing it as part of a seqscan only requires a buffer pin (and thus allows for concurrent writes to the same page) - It's hard to avoid repeated work with expressions that can't fully be evaluated as part of the ScanKey. Expression evaluation generally can be a bit smarter about evaluation, e.g. not deforming the tuple one-by-one. Greetings, Andres Freund
