Re: Performance monitor signal handler

I have a new statistics collection proposal.

I suggest three shared memory areas:

One per backend to hold the query string and other per-backend stats
One global area to hold accumulated stats for all backends
One global circular buffer to hold per-table/object stats

The circular buffer will look like:

(Loops) Start---------------------------End
|
current pointer

Loops is incremented every time the pointer reaches "end".

Each statistics record will have a length of five bytes made up of
oid(4) and action(1). By having the same length for all statistics
records, we don't need to perform any locking of the buffer. A backend
will grab the current pointer, add five to it, and write into the
reserved 5-byte area. If two backends write at the same time, one
overwrites the other, but this is just statistics information, so it is
not a great lose.

Only shared memory gives us near-zero cost for write/read. 99% of
backends will not be using stats, so it has to be cheap.

The collector program can read the shared memory stats and keep hashed
values of accumulated stats. It uses the "Loops" variable to know if it
has read the current information in the buffer. When it receives a
signal, it can dump its stats to a file in standard COPY format of
<oid><tab><action><tab><count>. It can also reset its counters with a
signal.

Comments?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026