> > I don't understand the attraction of the UDP stuff. If we have the
> > stuff in shared memory, we can add a collector program that gathers info
> > from shared memory and allows others to access it, right?
>
> There are a couple of problems with shared memory. First you
> have to decide a size. That'll limit what you can put into
> and if you want to put things per table (#scans, #block-
> fetches, #cache-hits, ...), you might run out of mem either
> way with complicated, multy-thousand table schemas.
>
> And the above illustrates too that the data structs in the
> shmem wouldn't be just some simple arrays of counters. So we
> have to deal with locking for both, readers and writers of
> the statistics.
[ Jan, previous email was not sent to list, my mistake.]
OK, I understand the problem with pre-defined size. That is why I was
looking for a way to dump the information out to a flat file somehow.
I think no matter how we deal with this, we will need some way to turn
on/off such reporting. We can write into shared memory with little
penalty, but network or filesystem output is not going to be near-zero
cost.
OK, how about a shared buffer area that gets written in a loop so a
separate collection program can grab the info if it wants it, and if
not, it just gets overwritten later. It can even be per-backend:
loops start end (loop to start)
----- [-----------------------------]
5 stat stat stat stat stat stat
|^^^
current pointer
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
