From: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
---|---|
To: | Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix parallel vacuum buffer usage reporting |
Date: | 2024-04-25 07:17:52 |
Message-ID: | CAO6_XqpCxQ0VkdkV_Ah_v=W1v3wt=pfGQssXGeuHrbMsUG=Bzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 24, 2024 at 4:01 PM Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>
wrote:
> I tested the main postgres branch with and without your fix using a script
> that was written by me. It consists of five scenarios and I made a
> comparison in the logs between the original version of the master branch
> and the master branch with your patch:
>
Hi! Thanks for the tests.
I have attached a test file (vacuum_check_logs.sql)
>
Looking at the script, you won't trigger the problem. The reporting issue
will only happen if there's a parallel index vacuum and it will only happen
if there's at least 2 indexes [0]. You will need to create an additional
index.
The same script was run, but using vacuum verbose analyze, and I saw the
> difference again in the fifth step:
> with your patch: buffer usage: 32312 hits, 607 misses, 1566 dirtied
> master: buffer usage: 32346 hits, 573 misses, 1360 dirtied
>
Isn't there a chance for the checkpointer to run during this time? That
could make the conditions between the two runs slightly different and
explain the change in buffer report.
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-04-25 07:20:05 | Re: Avoid orphaned objects dependencies, take 3 |
Previous Message | Frédéric Yhuel | 2024-04-25 07:13:07 | Re: New GUC autovacuum_max_threshold ? |