Re: Use streaming read I/O in BRIN vacuuming - Mailing list pgsql-hackers

From Arseniy Mukhin
Subject Re: Use streaming read I/O in BRIN vacuuming
Date
Msg-id CAE7r3MJ0hYznpwezvdrgimqcW6iyDH5op9mocL_VHjgpQdd6kg@mail.gmail.com
Whole thread Raw
In response to Re: Use streaming read I/O in BRIN vacuuming  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
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
everythingis 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PG 18 relnotes and RC1
Next
From: Mikael Kjellström
Date:
Subject: Re: ecpg test thread/alloc hangs on sidewinder running NetBSD 9.3