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 infinite size 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 providing some lookup protocol.
Now whatever the backend has to tell the collector, it simply
throws a UDP packet into his direction. If the collector can
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. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
