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
Simon Riggs [EMAIL PROTECTED] writes:
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
Gregory Stark [EMAIL PROTECTED] writes:
Sure, but I think Tom's question is how do you get from the plugin to wherever
you want this data to be? There's not much you can do with the data at that
point. You would end up having to reconstruct the entire stats collector
infrastructure to ship the
On Mon, 2007-07-02 at 17:41 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
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
I've got a requirement to produce some additional stats from the server
while it executes. Specifically, I'm looking at table interaction stats
to make it easier to determine replication sets accurately for a given
transaction mix.
On brief discussion, seems like a good approach would be to put
Simon Riggs [EMAIL PROTECTED] writes:
if (stats_hook)
(* stats_hook)(pgStatTabList);
Any objections to sliding this in?
Only that it's useless. What are you going to do in such a hook?
Not send more info to the stats collector, because the message format
is predetermined. AFAICS, if
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
if (stats_hook)
(* stats_hook)(pgStatTabList);
Any objections to sliding this in?
Only that it's useless. What are you going to do in such a hook?
Simon left for camping before you sent
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
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
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
It's certainly not intended as a one-off hack, but as a way of analysing
the behaviour
Tom Lane [EMAIL PROTECTED] writes:
So far it sounds terribly badly designed --- for starters, apparently it's
intending to ignore the stats aggregation/reporting infrastructure and
reinvent that wheel in some unspecified way, for unspecified reasons.
One way to accomplish the original goal
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
It's certainly not intended as a one-off hack, but as a way of
Gregory Stark [EMAIL PROTECTED] writes:
One way to accomplish the original goal by using the stats
aggregation/reporting infrastructure directly would be to add a stats_domain
guc which stats messages get tagged with. So you could have each application
domain set the guc to a different value
13 matches
Mail list logo
