Re: Vacuum statistics

From: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Jim Nasby <jnasby(at)upgrade(dot)com>, Andrei Zubkov <zubkov(at)moonset(dot)ru>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, a(dot)lepikhov(at)postgrespro(dot)ru
Subject: Re: Vacuum statistics
Date: 2024-12-02 20:12:05
Message-ID: 30d54302-9e9c-4e04-819e-a13b679cdcc8@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02.12.2024 11:27, Alexander Korotkov wrote:
> Hi, Alena!
>
> On Wed, Nov 13, 2024 at 6:21 PM Alena Rybakina
> <a(dot)rybakina(at)postgrespro(dot)ru> wrote:
>> Updated 0001-v13 attached, as well as the diff between v12 and v13.
>>
>> Thank you)
>>
>> And I agree with your changes. And included them in patches.
> Thank you for the updated patchset. Some points from me.
>
> * I've read the previous discussion on how important to keep all these
> fields regarding vacuum statistics including points by Andrei and Jim.
> It still worrying me that statistics volume is going to burst in about
> 3 times, but I don't have a particular proposal on how to make more
> granular approach. I wonder if you could propose something.
> * Previously PGSTAT_FILE_FORMAT_ID got increased by 1. Your 0001 patch
> increases it by 2. It's minor note, but I'd like to keep the
> tradition.
> * Commit message for 0001 looks nice, but commit messages of 0002,
> 0003, and 0004 look messy. Could you please, rearrange them.
> * The distinction between 0001 and 0002 is not clear. The first line
> of 0001 is "Machinery for grabbing an extended vacuum statistics on
> heap relations", the first line of 0002 is "Machinery for grabbing an
> extended vacuum statistics on heap and index relations." I guess 0001
> should be about heap relations while 0002 should be about just index
> relations. Is this correct?
> * I guess this statistics should work for any table AM, based on what
> has been done in relation_vacuum() interface method. If that's
> correct, we need to get rid of "heap" terminology and use "table"
> instead.
> * 0004 should be pure documentation patch, but it seems containing
> changes to isolation tests. Please, move them into a more appropriate
> place.
>
Thank you for your valuable feedback, I am already carefully processing
your comments and will update the patches soon.

I will think about what can be done to address the problem of increasing
the volume of statistics; perhaps it will be possible to implement a guc
that, when enabled, will accumulate additional information on vacuum
statistics. For example, this way you can group statistics by buffers
and vacuum statistics.

--
Regards,
Alena Rybakina
Postgres Professional

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-12-02 20:29:41 Re: Memory leak in WAL sender with pgoutput (v10~)
Previous Message Thomas Munro 2024-12-02 19:51:31 Re: RISC-V animals sporadically produce weird memory-related failures