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