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
statstat stat stat stat stat                        |^^^                        current pointer
 
--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026