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.96) (envelope-from ) id 1wD17h-002WTe-38 for pgsql-docs@arkaria.postgresql.org; Wed, 15 Apr 2026 14:21:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wD17e-00HLNE-38 for pgsql-docs@arkaria.postgresql.org; Wed, 15 Apr 2026 14:21:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wD13a-00Gfi7-0i for pgsql-docs@lists.postgresql.org; Wed, 15 Apr 2026 14:17:31 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wCwp9-00000001Bmi-2WMt for pgsql-docs@lists.postgresql.org; Wed, 15 Apr 2026 09:46:21 +0000 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-43d7badbd7dso1539852f8f.2 for ; Wed, 15 Apr 2026 02:46:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776246378; cv=none; d=google.com; s=arc-20240605; b=URmWfnIf0bvSB90zPoK1DbEjGjRMjf9ONz0YbKa0fKrExVaTyahvyhO5z+owAIlAeT j8jdClstb0DNjD27FRadrNanU3rOZDN5xxNicB5y09xcdMDy6i2PNcxwj43Gy+OAKn4Z Q3llIVJ0s3cTOCxxAXgm5aM6I+jjlP0RcHktxdePsBQcyA3aLmTvmNoGmVCAruvhZQ8B vWMpKT5snvb6JC4hYKb2cy/SmwMbNBiwTV/KfBMUjQInbFht6OvU0zgPjPTsBhQ/z07t lFK/JURDWz3GzzvMoMJ8WbICf4DweNu0Nop6nP23w2uAounxEx/3Brn8Zd+CeYdVq4QS zmXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=uN1JBDckieufQzSPFw19pw2gfHfuR3UG0pRli0vDmgA=; fh=56MvztVbbAFCHbUuaVf3ZuyqljvwSv9igeeRT9UVoqk=; b=MLAlHpJWj8RwpoD4xYYqLI75s/5Gy58grpDyxwa0lz+f3VpG+C8AqaeYb0PODe5ImR nOlOJerevJcO0YmZwG/lyjUHZDdAaUByghpfWtH5Mvu913jfeNvS1YaCjkM0H6sTgEHl 7eyxKDIKaph4KG3c3A3nYNIYZaTEa0X7Z8EPUzQDuoQHgX91x97q56609RbouRUdZxN0 9sVnxaldjdPa2Xv3OHslmQmjt1yCzdN85Np7ETvVJS2OaX26Wp25iVoEiZrW1Vy13sHC DFdjYXHz3+azqz0BZDApe0KEqqptT0bfAXs1UxktilBzB5dGQ3EzmiGQlIOhbQXct28l ly+A==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776246378; x=1776851178; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uN1JBDckieufQzSPFw19pw2gfHfuR3UG0pRli0vDmgA=; b=rozS2GUR/Jmc490H+my3+PUOn4aBq4eMDIdBRbn2VOP4PTXZRe4bqsg0VpG/TTKoB+ URMv707Bu41v6eHoeSTHzvt19HIxmn5SXgtaCcULC2VfsU3TKrql7ebmwNltNjJCo3Ve zWLiijmYMnu63ms21EPsgVhDmH1X+eZVbxiKouDcVAFP2gtwSd9WwP8Zp59DYafQFWES 5E7X7d19WKinil7RyewOKMxa7ps286RIG2T2zIfNMd1UyqagdkRzh7xZ+ZIxn9OEBmTg NwhP189cHrTwzTV/1eyoofIlpOtxf9APxg5kikxp2OjiP3UL9vntgm9bZJMSkcDEEFIr 0wuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776246378; x=1776851178; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uN1JBDckieufQzSPFw19pw2gfHfuR3UG0pRli0vDmgA=; b=eAwrLPECVrWy1UHN/hZwBioKbZC1AuIi0clpprU4L8G2ak0rfmhvSqwyJ8AkLVmOJJ M9YSNPffsE8BZzgePGxBU4wx3yaiAF/vcUVLJ1Y7kJqqgz695OXv05m7PPoO8EMBKEUj 5ROXp8nk+9N/XmRXZLVuZmyAYnbtNtTBldNuOdN9NXH+ubT4oEXxhqLTcvBsZTS2ZqQE GMLWTKfjfCbNq+UxMGjCYSKGlWG2S7AmkrKnl5vEgqA11La+txB7wxoN4ur1zrP/1020 Xhqxr93FRpR6dSFqsI/IsegML/dCUt/vU+XhTXNnlZ4ADK6IupwtkfNHtJuDjYVfDzpJ jL0g== X-Forwarded-Encrypted: i=1; AFNElJ8TKCw2ul7zPNAmzHMFia1+cW46p2cKJBcVg7KTOcbMBatJmi6u7OrDekcd3hCb8DvyVojjjNfBLWyg@lists.postgresql.org X-Gm-Message-State: AOJu0Yz4ErAjAdh/KhEbWV8/o3Ri8/tg+zhgk83c4hx6qOUN6jE0BCVD VJ8FPQvhYTG++zMODIzU/sY/v/MEqUptdKMrBeP2hENK4EW+M1eazkeX1KcsV/vbcuFoExUIdzc 8mdTPmH7XCrPBaDyOyAhSRsdda0hU8RU= X-Gm-Gg: AeBDieuQ8p2qr9heULo4WW5EAIDVnniCJEK5TuOFJNgceoVEP/n72msJjWOA0utzF25 /4FJJrSQIgbjJadO5G2Ge/yTlr1SUgAWZuzo0FZ5kleUollJ+KYwNMOFl+MA22kNPi0+fBfbfgd 4zurlDmwyxEIMu0hwfIsL7qo+Wdj+B05vnI8CpUtO+UzmnL7GGasH6+epBOXB3RaEvEHWFNX3Zg pM4xh1vOKtzPRUnsHqORxnZAEkyQ1Rdxpkvb9TV9Y+m/ZXiMoAWpEpj98o5xX2AXajI86z99g8X WBWRHpq1bX0N6DH07Jy2 X-Received: by 2002:a05:6000:4203:b0:43d:9bb5:bd97 with SMTP id ffacd0b85a97d-43d9bb5bfa7mr10689388f8f.8.1776246378217; Wed, 15 Apr 2026 02:46:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yushu Chen Date: Wed, 15 Apr 2026 17:45:41 +0800 X-Gm-Features: AQROBzCmsz3GRAU_BMaf1eGPTpcTs89h-Bo8PCvFq6NaQu7ju4LDjPo-EQQZD9E Message-ID: Subject: Re: doc: Clarify ANALYZE VERBOSE output To: "David G. Johnston" Cc: maciek@sakrejda.org, Shinya Kato , Fujii Masao , pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000068445d064f7c9679" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000068445d064f7c9679 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The discussion makes sense to me. Just to add one variant for consideration: "Emits detailed information about vacuum activity for each table in the form of INFO and DETAIL messages." Thanks. On Tue, Apr 14, 2026 at 6:29=E2=80=AFAM David G. Johnston < david.g.johnston@gmail.com> wrote: > On Mon, Apr 13, 2026 at 2:28=E2=80=AFPM Maciek Sakrejda > wrote: > >> On Tue, Apr 7, 2026 at 6:57=E2=80=AFPM Shinya Kato >> wrote: >> > On Mon, Apr 6, 2026, 14:17 David G. Johnston < >> david.g.johnston@gmail.com> wrote: >> >> >> >> How about something like: >> >> =E2=80=9CEnables sending an INFO message to the client (and server lo= g) as >> each table is processed. This message contains: etc=E2=80=A6=E2=80=9D >> >> >> >> And then let=E2=80=99s tell the user what info they are getting and w= hat it >> means (where necessary). >> >> >> >> I concur being specific about when these messages arrive, and IMO >> where, should be specified. But losing the detail of =E2=80=9Creport=E2= =80=9D is not good; >> but not sure why we are being vague so suggest we just go all-in on >> specificity. >> > >> > Thank you for the suggestion. I'd prefer to keep this patch focused; >> since the verbose output of both commands is subject to change, listing >> every individual field in the documentation would require frequent updat= es. >> > >> > I believe the current "Outputs" section is intentionally kept simple t= o >> minimize maintenance overhead. While expanding it might be a worthwhile >> follow-up, it probably deserves its own dedicated discussion. >> >> +1, listing output details is signing up for busywork. > > > Given how expansive and thorough our documentation is, and the fact this > is user-facing output, I'm not seeing why this gets a pass on the > documentation requirement. That said, I concur this patch needn't be > responsible for dealing with that - I'm not even sure whether trying to d= o > that on the vacuum/analyze pages is even the correct choice since at leas= t > some of what is output is object-specific and not generic to vacuum > itself. Though stuff like timings are. Even if we want to leave ourselv= es > the "it's undocumented so it can be changed at will" clause we can simply > write that in. > > maybe something >> along these lines: >> >> "Prints detailed stats at INFO level for each table >> as it is processed." >> >> > I really don't like the word "Print" here. What the client decides to do > with the INFO message is up to them - the interface to document for the > server is simply sending the message and its details. > > I was apparently mistaken about this info showing in the server log file > though. > > So that leaves me with suggesting: > > "Enables the sending of a detailed INFO message to the client after each > table is processed." > > David J. > > --00000000000068445d064f7c9679 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The discussion makes sense to me.
<= div class=3D"gmail_default" style=3D"font-family:simhei,sans-serif">
Jus= t to add one variant for consideration:

"Emits=C2=A0detailed=C2=A0information ab= out vacuum activity=C2=A0for each table in the form of INFO and DETA= IL messages."

Thanks.

On Tue, Apr 14, 20= 26 at 6:29=E2=80=AFAM David G. Johnston <david.g.johnston@gmail.com> wrote:
=
On Mon, Apr 13, 2026 at 2:28=E2=80=AFPM M= aciek Sakrejda <m.sakrejda@gmail.com> wrote:
On Tue, Apr 7, 20= 26 at 6:57=E2=80=AFPM Shinya Kato <shinya11.kato@gmail.com> wrote:
> On Mon, Apr 6, 2026, 14:17 David G. Johnston <david.g.johnston@gmail.com&g= t; wrote:
>>
>> How about something like:
>> =E2=80=9CEnables sending an INFO message to the client (and server= log) as each table is processed.=C2=A0 This message contains: etc=E2=80=A6= =E2=80=9D
>>
>> And then let=E2=80=99s tell the user what info they are getting an= d what it means (where necessary).
>>
>> I concur being specific about when these messages arrive, and IMO = where, should be specified.=C2=A0 But losing the detail of =E2=80=9Creport= =E2=80=9D is not good; but not sure why we are being vague so suggest we ju= st go all-in on specificity.
>
> Thank you for the suggestion. I'd prefer to keep this patch focuse= d; since the verbose output of both commands is subject to change, listing = every individual field in the documentation would require frequent updates.=
>
> I believe the current "Outputs" section is intentionally kep= t simple to minimize maintenance overhead. While expanding it might be a wo= rthwhile follow-up, it probably deserves its own dedicated discussion.

+1, listing output details is signing up for busywork.
Given how= expansive and thorough our documentation is, and the fact this is user-fac= ing output, I'm not seeing why this gets a pass on the documentation re= quirement.=C2=A0 That said, I concur this patch needn't be responsible = for dealing with that - I'm not even sure whether trying to do that on = the vacuum/analyze pages is even the correct choice since at least some of = what is output is object-specific and not generic to vacuum itself.=C2=A0 T= hough stuff like timings are.=C2=A0 Even if we want to leave ourselves the = "it's undocumented so it can be changed at will" clause we ca= n simply write that in.

m= aybe something
along these lines:

"Prints detailed stats at <literal>INFO</literal> level fo= r each table
as it is processed."


I really don't like the word &q= uot;Print" here.=C2=A0 What the client decides to do with the INFO mes= sage is up to them - the interface to document for the server is simply sen= ding the message and its details.

I was apparently mistaken about this info showing in the server log = file though.
So that leaves= me with suggesting:

"= Enables the sending of a detailed INFO message to the client after each tab= le is processed."

Davi= d J.

<= /div>
--00000000000068445d064f7c9679--