From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru> |
Cc: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Andrei Zubkov <zubkov(at)moonset(dot)ru>, Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com> |
Subject: | Re: Vacuum statistics |
Date: | 2025-04-22 18:23:57 |
Message-ID: | 631e09ab-099c-4089-883d-4524d852dfa2@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-22 18:25:02 | Re: Fortify float4 and float8 regression tests by ordering test results |
Previous Message | Sami Imseih | 2025-04-22 18:00:15 | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |