On 05.02.2025 09:59, Alexander Korotkov wrote:
What is the point for disabling pgstat_track_vacuum_statistics then?
I don't see it saves any valuable resources. The original point by
Masahiko Sawada was growth of data structures in times [1] (and
corresponding memory consumption especially with large number of
tables). Now, disabling pgstat_track_vacuum_statistics only saves
some cycles of pgstat_accumulate_extvac_stats(), and that seems
insignificant.
I see that we use hash tables with static element size. So, we can't
save space by dynamically changing entries size on the base of GUC.
But could we move vacuum statistics to separate hash tables? When GUC
is disabled, new hash tables could be just empty.
Links
1. https://www.postgresql.org/message-id/CAD21AoD66b3u28n%3D73kudgMp5wiGiyYUN9LuC9z2ka6YTru5Gw%40mail.gmail.com
I understand what you're talking about. I'm looking at the pgstat_assoc_relation function and I think that's where I need to decide whether we need to allocate memory in the hash table for vacuum statistics for them or not.
The same thing happens there depending on the installed pgstat_track_counts guc and pgstat_enabled value consequently. Like here:
Specifically, there is an example that for partitions, for example, statistics are not accumulated and the condition used like that, like here:
if (!pgstat_track_counts)
{
if (rel->pgstat_info)
pgstat_unlink_relation(rel);
/* We're not counting at all */
rel->pgstat_enabled = false;
rel->pgstat_info = NULL;
return;
}
I think I can try yo add an external parameter in the relation like ext_vacuum_pgstat_info and determine its values depending on the guc's pgstat_track_vacuum_statistics value.
--
Regards,
Alena Rybakina
Postgres Professional
