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 1t5jzS-0084Fu-Aa for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Oct 2024 11:02:22 +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 1t5jzQ-00FN5S-NC for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Oct 2024 11:02:21 +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 1t5jzQ-00FN4p-9H for pgsql-hackers@lists.postgresql.org; Tue, 29 Oct 2024 11:02:20 +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.94.2) (envelope-from ) id 1t5jzN-003RB2-1E for pgsql-hackers@postgresql.org; Tue, 29 Oct 2024 11:02:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1730199734; bh=NHAGTkA0q4K05GOx1pu7pdCiDq1V4G5/C3IbXkYINiI=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=l9PEGF4z/S1esNCYCONpECDag6VeeWRdatGi0ln++HTXQfp3NEOrRpUDoJOdY21Yf sUPz45LyG548mmsQXd/dQndb2zIEpvB24EixvhfN/Oi9eGxMfLAhymRgHHIf2Wx0AJ EoxsUYxSlz1wBy8QId6mbKmC26shRmV9H/BJZ4g9qW9WT3sEtzTlE0eutalvxWPQjI p8592mF8JRjXB25MY7MKv9RWBEdmUX6egBAwEj5rpJOqYkHFm2lSyr+oCPUHn7iE5y Psk462SyomL7yiKTYAWxY1e43Rnega7pDdm6Pt2EaY/ScTULtoPatJmPrx/qK4Rh/4 6KGKLAn0Hgxow== Received: from [172.30.33.154] (unknown [172.30.33.154]) (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 EF17560135; Tue, 29 Oct 2024 14:02:13 +0300 (MSK) Content-Type: multipart/alternative; boundary="------------iTqHY4Vl9xOkTNuFW5clD2fk" Message-ID: Date: Tue, 29 Oct 2024 14:02:13 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Vacuum statistics To: Alexander Korotkov Cc: Ilia Evdokimov , Andrei Zubkov , Alena Rybakina , pgsql-hackers , a.lepikhov@postgrespro.ru, jian he References: <53c47c2d-72a5-44f2-900c-9973b2af1808@tantorlabs.com> <4a902cea-54fb-41b5-b208-b84731a5f577@postgrespro.ru> <092adec6-4eae-4bd4-bd0d-473a9df1282b@tantorlabs.com> <3deae1bd-ad84-4459-a26e-04c9136b84e9@postgrespro.ru> Content-Language: en-US From: Alena Rybakina In-Reply-To: X-KSMG-AntiPhishing: NotDetected, bases: 2024/10/29 09: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: 2024/10/29 07:40:00 #26804951 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. --------------iTqHY4Vl9xOkTNuFW5clD2fk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 28.10.2024 16:40, Alexander Korotkov wrote: > On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina > wrote: >> I didn't understand correctly - did you mean that we don't need SRF if >> we need to display statistics for a specific object? >> >> Otherwise, we need this when we display information on all database >> objects (tables or indexes): >> >> while ((entry = ScanStatSnapshot(pgStatLocal.snapshot.stats, &hashiter)) >> != NULL) >> { >> CHECK_FOR_INTERRUPTS(); >> >> tabentry = (PgStat_StatTabEntry *) entry->data; >> >> if (tabentry != NULL && tabentry->vacuum_ext.type == type) >> tuplestore_put_for_relation(relid, rsinfo, tabentry); >> } >> >> I know we can construct a HeapTuple object containing a TupleDesc, >> values, and nulls for a particular object, but I'm not sure we can >> augment it while looping through multiple objects. >> >> /* Initialise attributes information in the tuple descriptor */ >> >> tupdesc = CreateTemplateTupleDesc(PG_STAT_GET_SUBSCRIPTION_STATS_COLS); >> >> ... >> >> PG_RETURN_DATUM(HeapTupleGetDatum(heap_form_tuple(tupdesc, values, nulls))); >> >> >> If I missed something or misunderstood, can you explain in more detail? > Actually, I mean why do we need a possibility to return statistics for > all tables/indexes in one function call? User anyway is supposed to > use pg_stat_vacuum_indexes/pg_stat_vacuum_tables view, which do > function calls one per relation. I suppose we can get rid of > possibility to get all the objects in one function call and just > return a tuple from the functions like other pgstatfuncs.c functions > do. > I haven’t thought about this before and agree with you. Thanks for the clarification! I'll fix the patch this evening and release the updated version. -- Regards, Alena Rybakina Postgres Professional --------------iTqHY4Vl9xOkTNuFW5clD2fk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 28.10.2024 16:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
<a.rybakina@postgrespro.ru> wrote:
I didn't understand correctly - did you mean that we don't need SRF if
we need to display statistics for a specific object?

Otherwise, we need this when we display information on all database
objects (tables or indexes):

while ((entry = ScanStatSnapshot(pgStatLocal.snapshot.stats, &hashiter))
!= NULL)
{
     CHECK_FOR_INTERRUPTS();

     tabentry = (PgStat_StatTabEntry *) entry->data;

     if (tabentry != NULL && tabentry->vacuum_ext.type == type)
         tuplestore_put_for_relation(relid, rsinfo, tabentry);
}

I know we can construct a HeapTuple object containing a TupleDesc,
values, and nulls for a particular object, but I'm not sure we can
augment it while looping through multiple objects.

/* Initialise attributes information in the tuple descriptor */

  tupdesc = CreateTemplateTupleDesc(PG_STAT_GET_SUBSCRIPTION_STATS_COLS);

...

PG_RETURN_DATUM(HeapTupleGetDatum(heap_form_tuple(tupdesc, values, nulls)));


If I missed something or misunderstood, can you explain in more detail?
Actually, I mean why do we need a possibility to return statistics for
all tables/indexes in one function call?  User anyway is supposed to
use pg_stat_vacuum_indexes/pg_stat_vacuum_tables view, which do
function calls one per relation.  I suppose we can get rid of
possibility to get all the objects in one function call and just
return a tuple from the functions like other pgstatfuncs.c functions
do.

I haven’t thought about this before and agree with you. Thanks for the clarification! I'll fix the patch this evening and release the updated version.
-- 
Regards,
Alena Rybakina
Postgres Professional
--------------iTqHY4Vl9xOkTNuFW5clD2fk--