Re: unnecessary executor overheads around seqscans

On Sat, Jan 24, 2026 at 1:46 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> - The checkXidAlive checks that have been added to table_scan_getnextslot()
> show up noticeably and in every loop iteration, despite afaict never being reachable
>
> It's not obvious to me that this should
> a) be in table_scan_getnextslot(), rather than in beginscan - how could it
> change in the middle of a scan? That would require a wrapper around
> rd_tableam->scan_begin(), but that seems like it might be good anyway.
> b) not just be an assertion?
>

IIRC, the main reason for having this precautionary check in the API
is to ensure that during logical decoding we never access the table AM
or
heap APIs directly when scanning catalog tables. This restriction
exists because we only check for concurrent aborts inside the
systable_* APIs.

In practice, the core code should never hit this precautionary check,
so it could likely be converted into an assert. The reason it may not
have been an assert originally is to give an ERROR if an output plugin
incorrectly invokes these APIs during decoding to access catalogs as
noted in docs [1] (Note that access to user catalog tables or regular
system catalog tables in the output plugins has to be done via the
systable_* scan APIs only. Access via the heap_* scan APIs will error
out.).

I'll think some more about it.

[1] - https://www.postgresql.org/docs/devel/logicaldecoding-output-plugin-writing.html

--
With Regards,
Amit Kapila.