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.
> Even better, have an SQL table updated with the per-table stats
> periodically.
That will be horribly expensive, if it's a real table.
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.
regards, tom lane
