On Fri, 2007-06-29 at 14:43 -0400, Tom Lane wrote:
> Dave Page <dpage@postgresql.org> writes:
> > Yes, it's not intended to insert more stats, but to get the raw data out
> > for external analysis during development and testing of applications and
> > systems etc.
>
> Mph --- the proposal was very poorly titled then. In any case, it still
> sounds like a one-off hack that would be equally well served by a local
> patch.
Well, I want it to a) be configurable b) provide additional stats, so
the title was fine, but we can call this whatever you like; I don't have
a fancy name for it.
The purpose is to get access to the stats data while we still know the
username, transactionId and other information. Once it is sent to the
stats collector it is anonymised and summarised.
Examples of the potential uses of such plug-ins would be:
1) Which tables have been touched by this transaction? The purpose of
this is to profile table interactions to allow:
i) an accurate assessment of the replication sets for use with Slony. If
you define the replication set incorrectly then you may not be able to
recover all of your data.
ii) determining whether it is possible to split a database that serves
two applications into two distinct databases (or not), allowing you to
scale out the Data Tier in a Service Oriented Application.
2) Charge-back accounting. Keep track by userid, user group, time of
access etc of all accesses to the system, so we can provide chargeback
facilities to users. You can put your charging rules into the plugin and
have it spit out appropriate chargeback log records, when/if required.
e.g. log a chargeback record every time a transaction touches > 100
blocks, to keep track of heavy queries but ignore OLTP workloads.
3) Tracing individual transaction types, as Greg suggests.
4) Anything else you might dream up...
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
