Re: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index - Mailing list pgsql-hackers

From Andrei Zubkov
Subject Re: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index
Date
Msg-id ce1cef8352e24260baa2f5101cb7119dc789f859.camel@moonset.ru
Whole thread Raw
In response to Re: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi Tom!
On Thu, 2022-03-24 at 16:34 -0400, Tom Lane wrote:
> I wrote:
> > After a bit of further fooling, I found that we could make that
> > work with LEFT JOIN LATERAL.  This formulation has a different
> > problem, which is that if you do want most or all of the output,
> > computing each sub-aggregation separately is probably less
> > efficient than it could be.  But this is probably the better way
> > to go unless someone has an even better idea.
> 
> Hearing no better ideas, pushed.
> 
>                         regards, tom lane

Thank you for your attention and for the problem resolution. However
I'm worry a little about possible performance issues related to
monitoring solutions performing regular sampling of statistic views to
find out the most intensive objects in a database. They obviously will
query all rows from statistic views and their impact will only depend
on the sampling frequency. Is it seems reasonable to avoid using
pg_statio_all_tables view by such monitoring tools? But it seems that
the only way to do so is using statistic functions directly in a
sampling query. Is it seems reliable? Maybe we should think about a
little bit different statio view for that? For example, a plain view
for all tables (regular and TOASTs)...
-- 
Regards, Andrei Zubkov





pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: shared-memory based stats collector - v66
Next
From: Amit Kapila
Date:
Subject: Re: Logical replication timeout problem