Re: Performance monitor signal handler

Bruce Momjian wrote:
>
> Yes, it seems storing info in shared memory and having a system table to
> access it is the way to go.
   Depends,
   first  of all we need to know WHAT we want to collect.  If we   talk about block read/write statistics  and  such
on a  per   table  base, which is IMHO the most accurate thing for tuning   purposes, then we're talking about an
infinitesize of shared   memory perhaps.
 
   And  shared  memory has all the interlocking problems we want   to avoid.
   What about a collector deamon, fired up by the postmaster and   receiving UDP packets from the backends. Under heavy
load,it   might miss some statistic messages, well, but that's  not  as   bad as having locks causing backends to loose
performance.
   The  postmaster  could already provide the UDP socket for the   backends, so the collector can know  the  peer
address from   which  to  accept  statistics messages only. Any message from   another peer address is  simply
ignored.  For  getting  the   statistics  out  of  it,  the  collector  has  his own server   socket, using TCP and
providingsome lookup protocol.
 
   Now whatever the backend has to tell the collector, it simply   throws  a UDP packet into his direction. If the
collectorcan   catch it or not, not the backends problem.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com