Message-ID: <631e09ab-099c-4089-883d-4524d852dfa2@gmail.com>
Date: Tue, 22 Apr 2025 20:23:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Vacuum statistics
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>
References: <bee34abe-fe87-49b3-8523-8ae19e641ccf@yandex.ru>
 <ff99283d-f9d4-4b37-b4fa-3a433fb408a4@tantorlabs.com>
 <e1f5b560691a4fe693625d529e19e13959210568.camel@moonset.ru>
 <53c47c2d-72a5-44f2-900c-9973b2af1808@tantorlabs.com>
 <c82e7776-7841-42a0-9247-878584174750@tantorlabs.com>
 <4a902cea-54fb-41b5-b208-b84731a5f577@postgrespro.ru>
 <CACJufxHb_YGCp=pVH6DZcpk9yML+SueffPeaRbX2LzXZVahd_w@mail.gmail.com>
 <CACJufxE6yAP+jUm4_GyKp7gUCkzbuJ9HGB-rR=92_hcLLZ9KTg@mail.gmail.com>
 <092adec6-4eae-4bd4-bd0d-473a9df1282b@tantorlabs.com>
 <3deae1bd-ad84-4459-a26e-04c9136b84e9@postgrespro.ru>
 <CAPpHfdug0s2MD7bBf-5nDQGn1WBxCKiTmZyGfxHz_7P0CDOjbg@mail.gmail.com>
 <c4e4e305-7119-4183-b49a-d7092f4efba3@postgrespro.ru>
 <CAPpHfdvSo3mfH=2m4ADCHAuN=22SnBY3TrPaPbGKTw3r_Jaw7Q@mail.gmail.com>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <CAPpHfdvSo3mfH=2m4ADCHAuN=22SnBY3TrPaPbGKTw3r_Jaw7Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/631e09ab-099c-4089-883d-4524d852dfa2%40gmail.com>
Precedence: bulk

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