Re: pg_stat_lwlock wait time view - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject Re: pg_stat_lwlock wait time view
Date
Msg-id 0A3221C70F24FB45833433255569204D1F5E0BCC@G01JPEXMBYT05
Whole thread Raw
In response to pg_stat_lwlock wait time view  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Haribabu Kommi
> calculations may cause performance problem. Is there any need of writing
> this stats information to file? As this just provides the wait time
> information.

Yes, saving the workload diagnosis information would be nice like Oracle AWR.  I mean not the current accumulated
total,but a series of snapshots taken periodically.  It would enable:
 

* Daily monitoring across database restarts.  e.g. The response times of applications degraded after applying a patch.
What'sthe difference between before and after the patch application?
 

* Hint on troubleshooting a crash failure.  e.g. Excessive memory use by PostgreSQL crashed the OS.  What was the
workloadlike just before the crash?
 

The point of discussion may be whether PostgreSQL itself provides the feature to accumulate performance diagnosis
informationon persistent storage.  pg_statsinfo will be able to take on it, but it wouldn't be convenient nor
efficient.

Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Better tracking of free space during SP-GiST index build
Next
From: Michael Paquier
Date:
Subject: Re: pg_dump with tables created in schemas created by extensions