Re: Performance monitor signal handler - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Performance monitor signal handler
Date
Msg-id 200103171743.MAA25369@candle.pha.pa.us
Whole thread Raw
In response to Re: Performance monitor signal handler  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance monitor signal handler
List pgsql-hackers
> 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
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Performance monitor signal handler
Next
From: Tom Lane
Date:
Subject: Re: Performance monitor signal handler