Re: pgmonitor patch for query string

> > 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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026