Re: Vacuum statistics

Sorry, I made a typo due to lack of sleep, I've marked below where 
exactly just in case.

On 10.01.2025 15:04, Alena Rybakina wrote:
>
> Hi, I have updated the patch. Fix minor mistakes in the document, 
> added the wraparound_failsafe_count statistics - it accounts the 
> number of times when the vacuum operates heap relation to prevent 
> workaround problem, fixed "shemaname".
>
I didn't mean workaround problem but wraparound problem.
>>> Secondly, where to put the total time of vacuum for indexes and databases?
>>> It would be incorrect not to take them into account at all. What if we remove the total time from
>>> the heap statistics and add it to pg_stat_tables and only leave the vacuum statistics total time of
>>> vacuum operation of indexes and databases?
>>> It seems strange to me that they will have to be viewed from different views.
>>>
>>> I think it is necessary to look at the total time for tables into perspective of how much
>>> time vacuum spent in total on processing indexes, since indexes can be bloated, for example.
>>> I think it is better to leave these statistics here.
>> You make valid points. I now think because track_vacuum_statistics is
>> optional, we should track total_time in 2 places. First place in the new
>> view being proposed here and the second place is in pg_stat_all_tables
>> as being proposed here [3]. This way if track_vacuum_statistics is off, the
>> total_time of vacuum could still be tracked by pg_stat_all_tables.
>>
>> By the way, the current patch does not track materialized view,
>> but it should as materialized views can also be vacuumed.
>>
>> Regards,
>>
>> Sami
>>
>> [1]https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE
>> [2]https://github.com/postgres/postgres/blob/master/src/backend/access/heap/vacuumlazy.c#L2437-L2444
>> [3]https://commitfest.postgresql.org/52/5485/
>>
>>
> I don't agree with this.
>
> Firstly, the hook is enabled by default, that is, it must be specially 
> disabled so that the vacuum statistics are not collected.
>
> Secondly, it will cause confusion. First, the hook was disabled and 
> statistics were collected in one place - pg_stat_all_tables, and then 
> it was enabled and the user notices that the statistics there stopped 
> accumulating,
> he is in a panic, "suddenly the vacuum does not work, what to do?". 
> The second point here bothers me, how to take into account this 
> statistics with the current detailed vacuum statistics? After all, 
> adding these values ​​​​is wrong -
> they do not show the correct statistics regarding the same pages 
> processed by vacuum, ignoring it later means that they will be 
> redundant. I think it is better to save it here, since this will save 
> us from possible confusion.
>
> Secondly, it will immediately show other important parameters 
> regarding this statistics - how long the vacuum was sleep (delay_time 
> in my patches), how much time the vacuum spent on processing indexes 
> during its processing.
> Without this information, this assessment will not be voluminous and 
> indicative enough.
>
I didn't mean hook but guc here.

-- 
Regards,
Alena Rybakina
Postgres Professional