Content-Type: multipart/alternative;
 boundary="------------A8oYpH8FsxdmbAx6P001H3OZ"
Message-ID: <c328ec87-72f5-43a2-b312-f9757a495d99@postgrespro.ru>
Date: Fri, 10 Jan 2025 17:51:10 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Vacuum statistics
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Jim Nasby <jnasby@upgrade.com>, Andrei Zubkov <zubkov@moonset.ru>,
 Masahiko Sawada <sawada.mshk@gmail.com>,
 Melanie Plageman <melanieplageman@gmail.com>,
 jian he <jian.universality@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>, a.lepikhov@postgrespro.ru
References: <bee34abe-fe87-49b3-8523-8ae19e641ccf@yandex.ru>
 <9b10c6d3-52c4-4eef-b67c-c33442667729@postgrespro.ru>
 <CAD21AoAVK7DwTZLfhwuRhTGgR=_ASu5YshEg_Cmpojk5ZdZ3tA@mail.gmail.com>
 <CAAKRu_auu=xt4w3Mm_jW-voJunZgno6XDDohH6hhRc4Z9dGdYQ@mail.gmail.com>
 <CAD21AoD66b3u28n=73kudgMp5wiGiyYUN9LuC9z2ka6YTru5Gw@mail.gmail.com>
 <9485d892-fd04-4e3a-ac24-7dd767cb7333@postgrespro.ru>
 <CAPpHfduwY8-fp34CuO9O57ouCs1K=Gn1rTnuG4AaWYhEo6nXyw@mail.gmail.com>
 <0B6CBF4C-CC2A-4200-9126-CE3A390D938B@upgrade.com>
 <6732acf8ce0f31025b535ae1a64568750924a887.camel@moonset.ru>
 <5AA8FFD5-6DE2-4A31-8E00-AE98F738F5D1@upgrade.com>
 <85b963fe-5977-43aa-9241-75b862abcc69@postgrespro.ru>
 <E0B6D242-C16D-4848-930E-B693D4E5C678@upgrade.com>
 <e2003f94-2075-4183-8298-9d25d8431fb1@postgrespro.ru>
 <9C7A167C-DCDE-4A17-9ABE-6276723FEC50@upgrade.com>
 <2d493cf9-9ba7-4cc1-a3f2-67afd7c163ee@postgrespro.ru>
 <CAPpHfds=woPcB9nPtMmu=g=U9q6-FHFh7fF_x=uhU3k2Oi03sA@mail.gmail.com>
 <30d54302-9e9c-4e04-819e-a13b679cdcc8@postgrespro.ru>
Content-Language: en-US
In-Reply-To: <30d54302-9e9c-4e04-819e-a13b679cdcc8@postgrespro.ru>
Archived-At: <https://www.postgresql.org/message-id/c328ec87-72f5-43a2-b312-f9757a495d99%40postgrespro.ru>
Precedence: bulk

This is a multi-part message in MIME format.
--------------A8oYpH8FsxdmbAx6P001H3OZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi! I thought about this problem again and I think I have a solution.

On 02.12.2024 23:12, Alena Rybakina wrote:
>> * 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.
We can collect statistics on databases at all times - there are less 
compared to vacuum statistics of relations, but they can give enough 
information that can hint that something is going wrong.
With the track_vacuum_statistics guc we can cover cases of collecting 
extended and complete information: when it is enabled, we will collect 
vacuum statistics on relations both: heaps and indexes.
This will not lead to a synchronicity between constant database 
statistics and temporary statistics of relations, since our vacuum 
statistics are cumulative and it is assumed that we will look at changes 
in statistics over a certain period.
What do you think?

-- 
Regards,
Alena Rybakina
Postgres Professional

--------------A8oYpH8FsxdmbAx6P001H3OZ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi! I thought about this problem again and I think I have a
      solution. </p>
    <div class="moz-cite-prefix">On 02.12.2024 23:12, Alena Rybakina
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:30d54302-9e9c-4e04-819e-a13b679cdcc8@postgrespro.ru">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
      <blockquote type="cite"
cite="mid:CAPpHfds=woPcB9nPtMmu=g=U9q6-FHFh7fF_x=uhU3k2Oi03sA@mail.gmail.com">
        <pre class="moz-quote-pre" wrap="">* 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.
</pre>
      </blockquote>
    </blockquote>
    We can collect statistics on databases at all times - there are less
    compared to vacuum statistics of relations, but they can give enough
    information that can hint that something is going wrong. <br>
    With the track_vacuum_statistics guc we can cover cases of
    collecting extended and complete information: when it is enabled, we
    will collect vacuum statistics on relations both: heaps and indexes.
    <br>
    This will not lead to a synchronicity between constant database
    statistics and temporary statistics of relations, since our vacuum
    statistics are cumulative and it is assumed that we will look at
    changes in statistics over a certain period. <br>
    What do you think?<br>
    <pre class="moz-signature" cols="72">-- 
Regards,
Alena Rybakina
Postgres Professional</pre>
  </body>
</html>

--------------A8oYpH8FsxdmbAx6P001H3OZ--