Horton

Re: Vacuum statistics

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>, Alena Rybakina <a.rybakina@postgrespro.ru>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, Andrei Zubkov <zubkov@moonset.ru>, Alena Rybakina <lena.ribackina@yandex.ru>, pgsql-hackers <pgsql-hackers@postgresql.org>, jian he <jian.universality@gmail.com>
Date: 2025-04-22T18:23:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move wal_buffers_full from PgStat_PendingWalStats to WalUsage

On 10/28/24 14:40, Alexander Korotkov wrote:
> On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
>> 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 suppose it was designed this way because databases may contain 
thousands of tables and indexes - remember, at least, partitions. But it 
may be okay to use the SRF_FIRSTCALL_INIT / SRF_RETURN_NEXT API. I think 
by registering a prosupport routine predicting cost and rows of these 
calls, we may let the planner build adequate plans for queries involving 
those stats - people will definitely join it with something else in the 
database.

-- 
regards, Andrei Lepikhov