public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alena Rybakina <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Jim Nasby <[email protected]>
Cc: Ilia Evdokimov <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Andrei Zubkov <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: jian he <[email protected]>
Cc: [email protected]
Cc: Sami Imseih <[email protected]>
Subject: Re: Vacuum statistics
Date: Wed, 5 Feb 2025 15:03:24 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAPpHfdvchPY9=gW2tL9awfh3kfFB0Ktt8K5F4kJgYRAWOrebrA@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfds=woPcB9nPtMmu=g=U9q6-FHFh7fF_x=uhU3k2Oi03sA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfduoJEuoixPTTg2tjhnXqrdobuMaQGxriqxJ9TjN1uxOuA@mail.gmail.com>
<[email protected]>
<CAPpHfdvchPY9=gW2tL9awfh3kfFB0Ktt8K5F4kJgYRAWOrebrA@mail.gmail.com>
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.g...
>
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_statisticsvalue.
--
Regards,
Alena Rybakina
Postgres Professional
view thread (37+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Vacuum statistics
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox