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: | Raw Message | Whole Thread | 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 |