Re: unnecessary executor overheads around seqscans

From: Andres Freund <andres(at)anarazel(dot)de>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Amit Langote <amitlangote09(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Re: unnecessary executor overheads around seqscans
Date: 2026-01-24 15:31:01
Message-ID: tlpltqm5jjwj7mp66dtebwwhppe4ri36vdypux2zoczrc2i3mp@dhv4v4nikyfg
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-01-24 15:23:44 +0530, Amit Kapila wrote:
> 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.

I know why the check exists - but why does it have to be in
table_scan_getnextslot(), which is executed very frequently, rather than
table_beginscan*(), which is executed much less frequently.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Junwang Zhao 2026-01-24 15:35:47 Re: Converting README documentation to Markdown
Previous Message Junwang Zhao 2026-01-24 15:26:54 Re: Extended Statistics set/restore/clear functions.