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 1t9UlH-00AXPB-G4 for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Nov 2024 19:35:15 +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 1t9UlE-00ClDC-Lr for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Nov 2024 19:35:13 +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 1t9UlE-00ClD3-6W for pgsql-hackers@lists.postgresql.org; Fri, 08 Nov 2024 19:35:12 +0000 Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t9UlB-000r2h-On for pgsql-hackers@postgresql.org; Fri, 08 Nov 2024 19:35:11 +0000 Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-718061440e2so55273a34.2 for ; Fri, 08 Nov 2024 11:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=upgrade.com; s=google; t=1731094508; x=1731699308; darn=postgresql.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=voCSgEH9Gzz6UfPv+yJGMnMAhdUSkdpwuzr01pw7t50=; b=YY4Y/92UVPd0MzcVxnvnT3j9Qy2fCMHWBlqK4kGDyBN9VxxPE2LwB/GNO3CBOSAIT+ j22qfMd5si3jqsH/Qfo0vX+qbJCWx5tg27AUM5+uxbjBBsk9Q56Lpk34XP/lYXd4lAJU 9vWzhH0hL9Ww1UtOOhiCnmExgyD0dkNrsF+U2Y5IBGu+N/hGFMkHrWSwOrO7PJRkTsSh kPEDUsvLeED9fxWjC0GzYyFvY6jUAPNz3FEuyjhqYQJk6Pi4I/u1X/pe/8kpT47f14wt vZD87bJ3//fjE5kKhpURkF/5OxLgKrGuOfc5N06BbZuMHTANa5im9lpuvNB+cSeYP6Bs yCRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731094508; x=1731699308; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=voCSgEH9Gzz6UfPv+yJGMnMAhdUSkdpwuzr01pw7t50=; b=Q9God7KCSDz4ihZ3sweM+FfrYfb+cqll+kvOdPv8xtpEJH03O1+ShqQuP7j7h2j8q5 hd2KaQRnntRYOzONtzuS8vOXfKU7h36WI03HttN64pyRqiFyd3n2i3KbsIrVqQmRhZT6 RyPddactoxKtcsztQXb1R2SDMLNx/2r4Bct7ByMC3Sr8n0jqpTfddA/ad6E54roF4mmY lSJxmayB6ogetteI5pLJ7SLxAd1LpqTVzS7vPlHO42/VB6Kr4B35i4pN1maD4WUk7roY A7WKlwv9YDkSdXT4k4jyF4B5aoVJZtMPoDKlYb6e2M8hLjJSRO+7s6hioPgK9lRi5efI KuLA== X-Forwarded-Encrypted: i=1; AJvYcCUY/Qij26pKo74BIe6oEGaoQDVnT34dhJzuLg5AQ1pC/quzU7d+ySxW+BGeT581hpq86TiJKdsdkXzsIEPR@postgresql.org X-Gm-Message-State: AOJu0YzDFYfIvTZP94yPHKeciUM0EQaBjexHL5kS77WDOhAql9dKzRdj duudOu4Yhw8HCXAA0I3d85sJ8AClGgAgRTA0PzAnm77VoyCUMsAHJlX4/noKnbc= X-Google-Smtp-Source: AGHT+IHdZKzRIhSM57LqYgAaSdwhlpxkZBc7EKPRK9705raybLutMYI0nFCa0hf2VYzA20IV4PB/jQ== X-Received: by 2002:a05:6808:21a6:b0:3e6:1a23:c3b2 with SMTP id 5614622812f47-3e7947286f0mr1023912b6e.10.1731094508477; Fri, 08 Nov 2024 11:35:08 -0800 (PST) Received: from smtpclient.apple (syn-070-113-014-216.res.spectrum.com. [70.113.14.216]) by smtp.gmail.com with ESMTPSA id 5614622812f47-3e78cc67256sm833438b6e.5.2024.11.08.11.35.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Nov 2024 11:35:08 -0800 (PST) From: Jim Nasby Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_26180991-CC86-4333-A47F-CA2266094AED" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) Subject: Re: Vacuum statistics Date: Fri, 8 Nov 2024 13:34:56 -0600 In-Reply-To: <85b963fe-5977-43aa-9241-75b862abcc69@postgrespro.ru> Cc: Andrei Zubkov , Alexander Korotkov , Masahiko Sawada , Melanie Plageman , jian he , pgsql-hackers , a.lepikhov@postgrespro.ru To: Alena Rybakina References: <092adec6-4eae-4bd4-bd0d-473a9df1282b@tantorlabs.com> <3deae1bd-ad84-4459-a26e-04c9136b84e9@postgrespro.ru> <9b10c6d3-52c4-4eef-b67c-c33442667729@postgrespro.ru> <9485d892-fd04-4e3a-ac24-7dd767cb7333@postgrespro.ru> <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> X-Mailer: Apple Mail (2.3776.700.51.11.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_26180991-CC86-4333-A47F-CA2266094AED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 2, 2024, at 7:22=E2=80=AFAM, Alena Rybakina = wrote: >=20 >>> The second is the interrupts field. It is needed for monitoring to = know >>> do we have them or not, so tracking them on the database level will = do >>> the trick. Interrupt is quite rare event, so once the monitoring = system >>> will catch one the DBA can go to the server log for the details. >> Just to confirm=E2=80=A6 by =E2=80=9Cinterrupt=E2=80=9D you mean = vacuum encountered an error? > Yes it is. In that case I feel rather strongly that we should label that as = =E2=80=9Cerrors=E2=80=9D. =E2=80=9CInterrupt=E2=80=9D could mean a few = different things, but =E2=80=9Cerror=E2=80=9D is very clear. > I updated patches. I excluded system and user time statistics and save = number of interrupts only for database. > I removed the ability to get statistics for all tables, now they can = only be obtained for an oid table [0], as suggested here. I also renamed = the statistics from pg_stat_vacuum_tables to pg_stat_get_vacuum_tables = and similarly for indexes and databases. I noticed that that=E2=80=99s = what they=E2=80=99re mostly called. Ready for discussion. >=20 I think it=E2=80=99s better that the views follow the existing naming = conventions (which don=E2=80=99t include =E2=80=9C_get_=E2=80=9D; only = the functions have that in their names). Assuming that, the only = question becomes pg_stat_vacuum_* vs pg_stat_*_vacuum. Given the = existing precedent of pg_statio_*, I=E2=80=99m inclined to go with = pg_stat_vacuum_*.= --Apple-Mail=_26180991-CC86-4333-A47F-CA2266094AED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 2, = 2024, at 7:22=E2=80=AFAM, Alena Rybakina = <a.rybakina@postgrespro.ru> wrote:

The second is the =
interrupts field. It is needed for monitoring to know
do we have them or not, so tracking them on the database level will do
the trick. Interrupt is quite rare event, so once the monitoring system
will catch one the DBA can go to the server log for the details.

Just to =
confirm=E2=80=A6 by =E2=80=9Cinterrupt=E2=80=9D you mean vacuum =
encountered an error?
Yes it = is.
In that case I feel rather strongly that = we should label that as =E2=80=9Cerrors=E2=80=9D. =E2=80=9CInterrupt=E2=80= =9D could mean a few different things, but =E2=80=9Cerror=E2=80=9D is = very clear.

I updated patches. I excluded system and user = time statistics and save number of interrupts only for database. I removed the ability to get statistics for all tables, now they can = only be obtained for an oid table [0], as suggested here. I also renamed = the statistics from pg_stat_vacuum_tables to pg_stat_get_vacuum_tables = and similarly for indexes and databases. I noticed that that=E2=80=99s = what they=E2=80=99re mostly called. Ready for = discussion.

I think it=E2=80=99s = better that the views follow the existing naming conventions (which = don=E2=80=99t include =E2=80=9C_get_=E2=80=9D; only the functions have = that in their names). Assuming that, the only question becomes = pg_stat_vacuum_* vs pg_stat_*_vacuum. Given the existing precedent of = pg_statio_*, I=E2=80=99m inclined to go with = pg_stat_vacuum_*.= --Apple-Mail=_26180991-CC86-4333-A47F-CA2266094AED--