From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Junwang Zhao <zhjwpku(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: Using read_stream in index vacuum |
Date: | 2024-10-23 17:57:28 |
Message-ID: | D8B329C5-6185-4B52-844C-A19321AD8202@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks!
> On 23 Oct 2024, at 18:17, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
>
>
> Note that you don't check if buf is valid here and break out of the
> inner loop when it is invalid.
I've added two asserts to clarify expectations.
>
> By doing read_stream_reset() before you first invoke
> read_stream_next_buffer(), seems like you invalidate the distance set
> in read_stream_begin_relation()
I've moved reset so happy path have a proper distance.
> Since you already advance a block number in the callback, I find it
> confusing to also use the block number as a loop condition here. I
> think it would be clearer to loop on read_stream_next_buffer()
> returning a valid buffer (and then move the progress reporting into
> btvacuumpage()).
I'll think how to restructure flow there...
I've also added a TAP test to check logic of stream resetting.
Best regards, Andrey Borodin.
Attachment | Content-Type | Size |
---|---|---|
v4-0001-Prototype-B-tree-vacuum-streamlineing.patch | application/octet-stream | 4.4 KB |
v4-0004-Move-reset.patch | application/octet-stream | 1.4 KB |
v4-0003-Add-asserts-to-address-review-feedback.patch | application/octet-stream | 918 bytes |
v4-0002-Add-TAP-tests-that-verifies-B-tree-vacuum.patch | application/octet-stream | 4.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-10-23 20:23:43 | Re: Fix for consume_xids advancing XIDs incorrectly |
Previous Message | Pavel Borisov | 2024-10-23 17:29:39 | Re: Refine comments on usage WL_POSTMASTER_DEATH vs WL_EXIT_ON_PM_DEATH |