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 1tXUDu-0080H0-1A for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jan 2025 23:51:59 +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 1tXUDr-00E9nE-SE for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jan 2025 23:51:56 +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 1tXUDr-00E9n6-46 for pgsql-hackers@lists.postgresql.org; Mon, 13 Jan 2025 23:51:55 +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 1tXUDo-000GNz-2U for pgsql-hackers@lists.postgresql.org; Mon, 13 Jan 2025 23:51:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1736812308; bh=yw6nAZnVFsTozxl1xwz5NGqZ4L6/NyXv4R2CT4bueYo=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=j4LVsRb4YRTYXExiBZEgaUvqBKH6owfTqLDI8V2A4JiOS3HBP6lkx64NYYgTVmwyf VfZ85CHvmCBc1z2H5neexMM4XSzD8h9sGqFBglCUG+GacSVpdQq8bYknEL9TMn1iFW cv8YPfkEXY9U3chVdyrnJ2OCJ1ioPSBeYbiO88aCqq/zsNc8PkSOj+4vWS0jySe1HX ZSdKY3lfaOolyRrtXEUITtHxwMKM4M/kIkL6cPsV4tMnxMp1CGWKzgsEJqHlgtgrVY M/cytwBqiNPimN6D/PSSjaoZYEyiS2+Xzv+CflgXAQ3QCXWJulz/OzUl64C83/zTUn DNj2aagrdkRnA== Received: from [172.20.10.4] (unknown [91.193.177.158]) (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 12809601ED; Tue, 14 Jan 2025 02:51:48 +0300 (MSK) Content-Type: multipart/alternative; boundary="------------uYxrGVaDdNXFNsR0LPxJ5xMy" Message-ID: Date: Tue, 14 Jan 2025 02:51:47 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: pgsql: Consolidate docs for vacuum-related GUCs in new subsection To: Melanie Plageman , Alvaro Herrera Cc: Tom Lane , Daniel Gustafsson , PostgreSQL Hackers References: <202501132046.m4mcvxxswznu@alvherre.pgsql> Content-Language: en-US From: Alena Rybakina In-Reply-To: X-KSMG-AntiPhishing: NotDetected, bases: 2025/01/13 21:46: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/01/13 14:44:00 #26997378 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. --------------uYxrGVaDdNXFNsR0LPxJ5xMy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi! On 14.01.2025 01:35, Melanie Plageman wrote: > On Mon, Jan 13, 2025 at 3:46 PM Alvaro Herrera wrote: >> On 2025-Jan-13, Melanie Plageman wrote: >> >>> Since I didn't hear back about this and I don't see an obvious >>> alternative reorganization in guc_tables.c, I plan to just push the >>> attached patch that updates only postgresql.conf.sample. >> Apologies, I was very unclear -- I didn't want to talk about the >> ordering of entries in the code, but the categorization. See the >> config_group_names list in guc_tables.c, which defines some groups. >> Each setting belongs into a group, and those groups correspond to what >> the sample config file lists as section/subsection titles and to the >> grouping in the docs. Also, this categorization affects how the entries >> are listed in the pg_settings view and in "postgres --describe-config", >> which feed from the same tables. > Oh dear, I had no idea that these categories existed. I suppose I > never paid attention to the category column in pg_settings nor used > --describe-config. Attached is a patch to fix this. I checked both > pg_settings and --describe-config output, and it seems to work. > > I'm quite sorry about the extra noise this is causing (especially for > people with patch sets requiring rebasing). > >> Perhaps with your changes (assuming I read your commit message right), >> we need new groups: >> VACUUMING >> VACUUMING_FREEZING >> VACUUMING_AUTOVACUUM > I've gone with VACUUM_AUTOVACUUM, VACUUM_COST_DELAY, and > VACUUM_FREEZING, but I am open to feedback. Looks good and convenient, thanks for the patch! I noticed another guc autovacuum_work_mem, which belongs more to the autovacuum category in my opinion, although it belongs to RESOURCES_MEM, but in fact, only autovacuum uses it. -- Regards, Alena Rybakina Postgres Professional --------------uYxrGVaDdNXFNsR0LPxJ5xMy Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi!

On 14.01.2025 01:35, Melanie Plageman wrote:
On Mon, Jan 13, 2025 at 3:46 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2025-Jan-13, Melanie Plageman wrote:

Since I didn't hear back about this and I don't see an obvious
alternative reorganization in guc_tables.c, I plan to just push the
attached patch that updates only postgresql.conf.sample.
Apologies, I was very unclear -- I didn't want to talk about the
ordering of entries in the code, but the categorization.  See the
config_group_names list in guc_tables.c, which defines some groups.
Each setting belongs into a group, and those groups correspond to what
the sample config file lists as section/subsection titles and to the
grouping in the docs.  Also, this categorization affects how the entries
are listed in the pg_settings view and in "postgres --describe-config",
which feed from the same tables.
Oh dear, I had no idea that these categories existed. I suppose I
never paid attention to the category column in pg_settings nor used
--describe-config. Attached is a patch to fix this. I checked both
pg_settings and --describe-config output, and it seems to work.

I'm quite sorry about the extra noise this is causing (especially for
people with patch sets requiring rebasing).

Perhaps with your changes (assuming I read your commit message right),
we need new groups:
VACUUMING
VACUUMING_FREEZING
VACUUMING_AUTOVACUUM
I've gone with VACUUM_AUTOVACUUM, VACUUM_COST_DELAY, and
VACUUM_FREEZING, but I am open to feedback.

Looks good and convenient, thanks for the patch!

I noticed another guc autovacuum_work_mem, which belongs more to the autovacuum category in my opinion, although it belongs to RESOURCES_MEM, but in fact, only autovacuum uses it.

-- 
Regards,
Alena Rybakina
Postgres Professional
--------------uYxrGVaDdNXFNsR0LPxJ5xMy--