> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The only open issue is per-table stuff, and I would like to see some
> > circular buffer implemented to handle that, with a collection process
> > that has access to shared memory.
>
> That will get us into locking/contention issues. OTOH, frequent trips
> to the kernel to send stats messages --- regardless of the transport
> mechanism chosen --- don't seem all that cheap either.
I am confused. Reading/writing shared memory is not a kernel call,
right?
I agree on the locking contention problems of a circular buffer.
>
> > Even better, have an SQL table updated with the per-table stats
> > periodically.
>
> That will be horribly expensive, if it's a real table.
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?
-- 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
