Re: Vacuum statistics - Mailing list pgsql-hackers

From Alena Rybakina
Subject Re: Vacuum statistics
Date
Msg-id a7f1f8f5-075c-4b77-8ab6-c19546037c43@yandex.ru
Whole thread Raw
In response to Re: Vacuum statistics  (Alena Rybakina <a.rybakina@postgrespro.ru>)
List pgsql-hackers

Hi!

On 29.10.2024 14:02, Alena Rybakina wrote:
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.

I updated the patches as per your suggestion. You can see it here [0].

[0] https://www.postgresql.org/message-id/85b963fe-5977-43aa-9241-75b862abcc69%40postgrespro.ru

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Fix for Extra Parenthesis in pgbench progress message
Next
From: Bruce Momjian
Date:
Subject: Re: Doc: typo in config.sgml