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
