Re: Rethinking stats communication mechanisms

> > Might it not be a win to also store "per backend global
> values" in the
> > shared memory segment? Things like "time of last command",
> "number of
> > transactions executed in this backend", "backend start
> time" and other
> > values that are fixed-size?
>
> I'm including backend start time, command start time, etc
> under the heading of "current status" which'll be in the
> shared memory. However, I don't believe in trying to count
> events (like transaction commits) that way. If we do then we
> risk losing events whenever a backend quits and is replaced
> by another.

Well, in many cases that's not a problem. It might be interesting to for
example know that a backend has run nnn transactions before ending up in
the state where it is now (say, idle in transaction and idle for a long
time). The part about this being "transient data" that can go away along
with a backend quit would still hold true.

What were your thoughts about storing bgwriter and archiver statistics
that way? Good or bad idea?

> I haven't yet looked through the stats in detail, but this
> approach basically presumes that we are only going to count
> events per-table and per-database --- I am thinking that the
> background stats collector process won't even keep track of
> individual backends anymore. (So, we'll fix the old problem
> of loss of backend-exit messages resulting in bogus displays.)

Right. As I see you have now implemented ;-)

/Magnus