From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Rethinking stats communication mechanisms |
Date: | 2006-06-18 19:30:19 |
Message-ID: | 1150659019.3769.37.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ühel kenal päeval, P, 2006-06-18 kell 15:09, kirjutas Tom Lane:
> "Magnus Hagander" <mha(at)sollentuna(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-18 21:26:16 | Re: Rethinking stats communication mechanisms |
Previous Message | Tom Lane | 2006-06-18 19:09:14 | Re: Rethinking stats communication mechanisms |