| From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
|---|---|
| To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: RFC: built-in historical query time profiling |
| Date: | 2005-03-23 23:11:41 |
| Message-ID: | 4241F7AD.8000503@paradise.net.nz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ed L. wrote:
> Hackers,
> (some snippage...)
> Our Problem: We work with 75+ geographically distributed pg
> clusters; it is a significant challenge keeping tabs on
> performance. We see degradations from rogue applications,
> vacuums, dumps, bloating indices, I/O and memory shortages, and
> so on. Customers don't generally tell us when applications are
> slow, so we need to know for ourselves in a timely manner. At
> present, we can remotely and systematically query system
> relations for diskspace usage, detailed I/O usage,
> index/sequential scans, and more. But our _ultimate_ DB
> performance measure is query execution time. Obviously, you can
> measure that now in an ad hoc fashion with EXPLAIN ANALYZE, and
> by examining historical logs. But we need to be able to see the
> history in a timely fashion to systematically identify
> customer-experienced execution time degradations for "query
> patterns of interest" without any visual log inspection
> whatsoever, and correlate those with other events.
Is enabling the various postgresql.conf stats* options and taking
regular snapshots of pg_stat_activity a possible way to get this?
regards
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ed L. | 2005-03-23 23:35:35 | Re: RFC: built-in historical query time profiling |
| Previous Message | Tom Lane | 2005-03-23 22:34:46 | Re: RFC: built-in historical query time profiling |