Re: Rethinking stats communication mechanisms

> It strikes me that we are using a single communication mechanism to
> handle what are really two distinct kinds of data:

Interesting.

I recently read a paper on how to get rid of locks for this kind of
pattern.

* For the Command String

- Problem : need to display the currently executing command in the ps
list.
- Will only be of use if the command is taking a long, long time.
So, it need not be realtime ; no problem if the data comes with a little
delay, or not at all if the command executes quickly.
People are only interested in the currently executing command to answer
questions like "what query has my server grinding ?"

Point : the currently executing query is only interesting to display if
it's currently executing. If it's not, it's in the log (if enabled).

So, the proposal :

Each backend has a shared memory area where to store :
- the currently executing command (like in your proposal).
- a timestamp
- a counter

On executing a command, Backend stores the command string, then
overwrites the counter with (counter + 1) and with the timestamp of
command start.

Periodically, like every N seconds, a separate process reads the counter,
then reads the data, then reads the counter again.
If the counter value changed, the process is repeated. If the counter
value did not change, the command string did not change either, so it's
valid, and can be used.

Other thoughts :

If the backend process itself should update its process title, and this
operation is costly, it should only be done if the current query has been
running for more than T seconds. However syscalls for getting the current
time are costly. A separate process can update a counter in shared memory
with the current time every N seconds, and the backend can check it.

The main point is that if this value is written to every few seconds, but
read often by only one process ; or written often but read seldom, there
will not be a lot of interprocessor cache trashing on it.