RE: [Proposal] Add accumulated statistics - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: [Proposal] Add accumulated statistics
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB62259@G01JPEXMBYT05
Whole thread Raw
In response to RE: [Proposal] Add accumulated statistics  ("Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>)
List pgsql-hackers
From: Yotsunaga, Naoki [mailto:yotsunaga.naoki@jp.fujitsu.com]
> By the way, you can see the number of wait events with "LWLOCK_STATS", right?
> Is this function implemented because it is necessary to know the number
> of waiting events for investigation?
> If so, is not that the number of wait events is useful information?
> Now, I need to rebuild to get this information and I feel inconvenience.
> 
> So, how about checking the number of wait events in the view?
> Also, I think that it will be useful if you know the waiting time.
> I think that it is easy to investigate when it is clearly known how long
> waiting time is occupied with processing time.

That's interesting.  It should be convenient for PG developers to be able to see wait events of each session and the
wholeinstance to improve PostgreSQL.  I developed a flight recorder feature for a proprietary database (not based on
PostgreSQL),which recorded various events, including waits, in the ring buffer for each session.  It could dump the
ringbuffers into external files in CSV format, so that we can load them into a database or a spreadsheet to analyze the
timemodel of SQL execution.  That helped us a lot to eliminate many bottlenecks.  MySQL says a similar thing about its
PerformanceSchema:
 

https://dev.mysql.com/doc/refman/8.0/en/performance-schema-examples.html

"Tune the code (this applies to storage engine or server developers only)."



Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Next
From: Tatsuo Ishii
Date:
Subject: Re: Implementing Incremental View Maintenance