Re: Rethinking stats communication mechanisms
От | Tom Lane |
---|---|
Тема | Re: Rethinking stats communication mechanisms |
Дата | |
Msg-id | 18071.1150657754@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Rethinking stats communication mechanisms ("Magnus Hagander" <mha@sollentuna.net>) |
Ответы |
Re: Rethinking stats communication mechanisms
Re: Rethinking stats communication mechanisms |
Список | pgsql-hackers |
"Magnus Hagander" <mha@sollentuna.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
В списке pgsql-hackers по дате отправления: