On Fri, 2007-06-29 at 14:43 -0400, Tom Lane wrote: > Dave Page <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
