Re: Using read_stream in index vacuum

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

In response to

Responses

Browse pgsql-hackers by date

  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