Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfe82-003xTd-SV for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Feb 2025 12:03:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tfe81-00E6qo-Tw for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Feb 2025 12:03:37 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfe81-00E6qg-9t for pgsql-hackers@lists.postgresql.org; Wed, 05 Feb 2025 12:03:37 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tfe7t-003J0t-29 for pgsql-hackers@postgresql.org; Wed, 05 Feb 2025 12:03:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1738757006; bh=UQN12OK1bBcs/51dflkilQnnYjZOL63xMjFXQtAlmyI=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=1Ru1cia/ligWcdJePrjq1iX0/M0L9R8dZ63VFizQIieRIim86FHQ6qh1NwFIfOC+z TQxEGfrrB2W8x1PXsSfxUO/gcjejW1yZzoB4N+8gNGsRUaBRy8VV/YvSsVtGRCNONb +Bj8WKv1LIV6eBLoXqpuiWYT5vhHo+MI/K2QNJvfvtY4PfQ6YoQ14qOgg2JQ9Vciv5 f47wJDdaBYZkX234a91nDRmj3mWcKFvcIEJWKPY/Ii5InNTBzyrZUSbHKF00Qk3R6+ ioGireNKbvdpo+QSMJgoNPOhaDFCcrW/mz3TXzjtu+CXot3UhmwMZiRTWXvzQE1JDy UfXHW5pKvT6Yw== Received: from [172.20.10.4] (unknown [89.113.145.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.rybakina@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id CDC086084F; Wed, 5 Feb 2025 15:03:25 +0300 (MSK) Content-Type: multipart/alternative; boundary="------------pO0Njl0baheVk4NV0HkL924L" Message-ID: Date: Wed, 5 Feb 2025 15:03:24 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Vacuum statistics To: Alexander Korotkov Cc: pgsql-hackers , Jim Nasby , Ilia Evdokimov , Kirill Reshke , Andrei Zubkov , Masahiko Sawada , Melanie Plageman , jian he , a.lepikhov@postgrespro.ru, Sami Imseih References: <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> <9C7A167C-DCDE-4A17-9ABE-6276723FEC50@upgrade.com> <2d493cf9-9ba7-4cc1-a3f2-67afd7c163ee@postgrespro.ru> <30d54302-9e9c-4e04-819e-a13b679cdcc8@postgrespro.ru> <86f76aa5-1ab5-4e2e-9b15-405051852a2a@postgrespro.ru> <1e81a0a1-a63b-48fb-905a-d6495f89ab73@postgrespro.ru> <0b4eefc7-4c38-4caa-b2ca-a4c75dd7dd12@postgrespro.ru> Content-Language: en-US From: Alena Rybakina In-Reply-To: X-KSMG-AntiPhishing: NotDetected, bases: 2025/02/05 10:49:00 X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2025/02/04 17:16:00 #27210181 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------pO0Njl0baheVk4NV0HkL924L Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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_statisticsvalue. -- Regards, Alena Rybakina Postgres Professional --------------pO0Njl0baheVk4NV0HkL924L Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
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
--------------pO0Njl0baheVk4NV0HkL924L--