From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Rethinking stats communication mechanisms |
Date: | 2006-06-18 19:09:14 |
Message-ID: | 18071.1150657754@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> 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.
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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-06-18 19:30:19 | Re: Rethinking stats communication mechanisms |
Previous Message | Magnus Hagander | 2006-06-18 19:01:05 | Re: Rethinking stats communication mechanisms |