Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 8EBEE9FB6AD
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Sun, 13 May 2007 01:41:30 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 50146-04 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Sun, 13 May 2007 01:41:15 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from mailbox.samurai.com (mailbox.samurai.com [205.207.28.82])
	by postgresql.org (Postfix) with ESMTP id 6183D9FB502
	for <pgsql-hackers@postgresql.org>;
	Sun, 13 May 2007 01:41:27 -0300 (ADT)
Received: from localhost (mailbox.samurai.com [205.207.28.82])
	by mailbox.samurai.com (Postfix) with ESMTP id 95D6461D19;
	Sun, 13 May 2007 00:41:26 -0400 (EDT)
X-Virus-Scanned: by amavisd-new at mailbox.samurai.com
Received: from mailbox.samurai.com ([205.207.28.82])
	by localhost (mailbox.samurai.com [205.207.28.82]) (amavisd-new,
	port 10024)
	with LMTP id SEKXdStfZxM0; Sun, 13 May 2007 00:41:25 -0400 (EDT)
Received: from [192.168.0.101]
	(CPE3285f62f0d42-CM0011aec5ebbc.cpe.net.cable.rogers.com
	[74.103.69.144]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by mailbox.samurai.com (Postfix) with ESMTP id 4513361D05;
	Sun, 13 May 2007 00:41:25 -0400 (EDT)
Subject: Re: Performance monitoring
From: Neil Conway <neilc@samurai.com>
To: "Joshua D. Drake" <jd@commandprompt.com>
Cc: "Jim C. Nasby" <decibel@decibel.org>,
	Heikki Linnakangas <heikki@enterprisedb.com>,
	Greg Smith <gsmith@gregsmith.com>, pgsql-hackers@postgresql.org
In-Reply-To: <464630EA.5000701@commandprompt.com>
References: <Pine.GSO.4.64.0704010051050.14920@westnet.com>
	<200704030814.33999.peter_e@gmx.net>
	<Pine.GSO.4.64.0704030927180.5732@westnet.com>
	<46443F02.6060300@enterprisedb.com>
	<Pine.GSO.4.64.0705111009080.18685@westnet.com>
	<46448DC8.4050102@enterprisedb.com> <20070512211948.GA58786@nasby.net>
	<464630EA.5000701@commandprompt.com>
Content-Type: text/plain
Date: Sun, 13 May 2007 00:41:24 -0400
Message-Id: <1179031284.2830.19.camel@goldbach>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200705/487
X-Sequence-Number: 103089

On Sat, 2007-12-05 at 14:26 -0700, Joshua D. Drake wrote:
> Either way, we are taking the hit, it is just a matter of where. IMO it 
> would be better to have the information in the database where it makes 
> sense, than pushing out to a log

If performance monitoring information is provided as a database object,
what would the right interface be? IMHO the problem with cleanly
presenting monitoring information within a normal database system is
that this sort of data is fundamentally dynamic and continuous: to
determine how the performance of the system changes over time, you need
to repeatedly rescan the table/view/SRF and recompute your analysis
essentially from scratch. Trying to get even simple information like
"queries per second" from pg_stat_activity is an example of how this can
be painful.

<plug>
BTW, if the system included the concept of a continuous data *stream* as
a kind of database object, this problem would be much more tractable :)
In fact, there is some code in a version of TelegraphCQ that exposes
various information about the runtime state of the system as a set of
system-defined data streams -- like any other stream, users could then
use those streams in arbitrary queries.
</plug>

-Neil