Horton

Re: Use streaming read I/O in BRIN vacuuming

Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>

View thread
From: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-31T19:47:41Z
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. Use streaming read I/O in BRIN vacuum scan.

Hi!

On Sun, Aug 31, 2025 at 8:49 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> Hi!
>
> > On 31 Aug 2025, at 21:17, Arseniy Mukhin <arseniy.mukhin.dev@gmail.com> wrote:
> >
> > PFA the patch that migrates BRIN vacuum to the read stream API.
>
> The patch is nice and straightforward. Looks good to me.
>

Thank you for the review!

> Some notes that do not seem to me problem of this patch:
> 1. This comment is copied 7 times already across codebase.
> "It is safe to use batchmode as block_range_read_stream_cb"
> Maybe we can refactor comments and function names...

Yes, I had similar thoughts, but having these comments at callsites
has its own benefits, there is a thread about these comments [0]...

> 2. Somehow brin_vacuum_scan() avoid dance of getting RelationGetNumberOfBlocks() many times to be entirely sure everything is scanned. Unlike other index vacuums, see btvacuumscan() for example.

If I understand correctly, in other access methods you need to be sure
that you read the relation up to the end, so you don't leave any index
tuples that should be pruned. BRIN doesn't have a prune phase, there
is only a cleanup phase. So it seems it's not a big deal if you miss
several pages that were allocated during the vacuum.


[0] https://www.postgresql.org/message-id/flat/CAE7r3M%2BP1Qcv7CYxi%3DJw_d40L%3DsVRAxdDti-Vo4X5x0opZ3XVw%40mail.gmail.com


Best regards,
Arseniy Mukhin