Horton

Re: Some ExecSeqScan optimizations

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Nikita Malakhov <hukutoc@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>, David Rowley <dgrowleyml@gmail.com>, Vladlen Popolitov <v.popolitov@postgrespro.ru>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Junwang Zhao <zhjwpku@gmail.com>
Date: 2025-07-11T14:37:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Refactor ExecScan() to allow inlining of its core logic

Hi,

On 2025-07-11 14:03:42 +0300, Nikita Malakhov wrote:
> It's a pity I missed this thread when you developed the patch.
> I've developed a feature recently and discovered that SeqScan
> does not make use of scan keys, and there is a Tom Lane's
> comment regarding this:
>   * Note that unlike IndexScan, SeqScan never use keys in heap_beginscan
>   * (and this is very bad) - so, here we do not check are keys ok or not.
> 
> Have you considered passing scan keys like it is done in IndexScan?

You can't easily do that without causing issues:

1) ScanKeys are evaluated while holding a buffer lock, we shouldn't do that
   with arbitrary functions (since they could recurse and acquire other locks
   in a non-correct order)

2) ScanKeys are rather restrictive in what they can express, but not
   restrictive enough to make 1) not a problem. That means that you can't just
   evaluate the whole predicate using ScanKeys.

3) ScanKey evaluation is actually sometimes *more* expensive than expression
   evaluation, because the columns are deformed one-by-one.

Greetings,

Andres Freund