Re: Rethinking stats communication mechanisms - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Rethinking stats communication mechanisms
Date
Msg-id 1150659019.3769.37.camel@localhost.localdomain
Whole thread Raw
In response to Re: Rethinking stats communication mechanisms  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Ühel kenal päeval, P, 2006-06-18 kell 15:09, kirjutas Tom Lane:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > Might it not be a win to also store "per backend global values" in the
> > shared memory segment? Things like "time of last command", "number of
> > transactions executed in this backend", "backend start time" and other
> > values that are fixed-size?

One thing that is doable in constant size memory and would be enormously
usable for us is counting to-level function calls and storing their
total (and possibly also max) duration.

The resaon being, that our production databases are accessed by clients
using  functions only (with some uninteresting exeptions of course),
that is call in form of "SELECT x,y,z FROM myfunc(i,j,k)"

So reserving N*1.5 slots (N being the number of functions defined at
databse startup) would be ok. If more than N*0.5 functions are defined
in the database lifetime, then the rest are simply ignored (not
counted).

Or maybe a better approach would be to have a conf variable
"number-of-functions-to-track" and a special boolean flag track_me in
pg_functions. In this way you don't accidentally run out of shared mem
by defining lots of new functions and then restarting the cluster.


-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rethinking stats communication mechanisms
Next
From: Tom Lane
Date:
Subject: Re: Rethinking stats communication mechanisms