From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Haribabu Kommi' <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_lwlock wait time view |
Date: | 2016-08-25 00:30:58 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F5E0BCC@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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's the 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 workload like just before the crash?
The point of discussion may be whether PostgreSQL itself provides the feature to accumulate performance diagnosis information on persistent storage. pg_statsinfo will be able to take on it, but it wouldn't be convenient nor efficient.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-08-25 00:34:53 | Re: pg_dump with tables created in schemas created by extensions |
Previous Message | Tom Lane | 2016-08-24 23:45:50 | Better tracking of free space during SP-GiST index build |