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 chargi
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 shi
"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 charg
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 po
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 va
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
"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
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
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 sti
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
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 ca
"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 this. M
"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
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 in
14 matches
Mail list logo
