Re: RFC: Table access methods and scans - Mailing list pgsql-hackers

From Andres Freund
Subject Re: RFC: Table access methods and scans
Date
Msg-id 20210611190908.srxx4hp7io6hrkkc@alap3.anarazel.de
Whole thread Raw
In response to Re: RFC: Table access methods and scans  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Question about StartLogicalReplication() error path
Next
From: Andres Freund
Date:
Subject: Re: [Proposal] Add accumulated statistics for wait event