Re: RFC: Table access methods and scans

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