Re: pg_stat_lwlock wait time view

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
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.

Takayuki Tsunakawa

In response to

Browse pgsql-hackers by date

  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