Re: Performance monitor signal handler

> > But per-table stats aren't something that people will look at often,
> > right?  They can sit in the collector's memory for quite a while.  See
> > people wanting to look at per-backend stuff frequently, and that is why
> > I thought share memory should be good, and a global area for aggregate
> > stats for all backends.
> 
> >> I think you missed the point that somebody made a little while ago
> >> about waiting for functions that can return tuple sets.  Once we have
> >> that, the stats tables can be *virtual* tables, ie tables that are
> >> computed on-demand by some function.  That will be a lot less overhead
> >> than physically updating an actual table.
> 
> > Yes, but do we want to keep these stats between postmaster restarts? 
> > And what about writing them to tables when our storage of table stats
> > gets too big?
> 
> All those points seem to me to be arguments in *favor* of a virtual-
> table approach, not arguments against it.
> 
> Or are you confusing the method of collecting stats with the method
> of making the collected stats available for use?

Maybe I am confusing them.  I didn't see a distinction in the
discussion.

I assumed the UDP/message passing of information to the collector was
the way statistics were collected, and I don't understand why a
per-backend area and global area, with some kind of cicular buffer for
per-table stuff isn't the cheapest, cleanest solution.

--  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