Re: Performance monitor signal handler

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> 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?

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?

regards, tom lane