Re: pgstat: delayed write of stats file

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: pgstat: delayed write of stats file
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA3525A@algol.sollentuna.se
обсуждение исходный текст
Ответ на pgstat: delayed write of stats file  ("Magnus Hagander" <mha@sollentuna.net>)
Список pgsql-patches
> > And it is now also written on backend request. A backend requests a
> > rewrite by simply sending a special stats message. It
> operates on the
> > assumption that the backends aren't actually going to read the
> > statistics file very often, compared to how frequent it's
> written today.
>
> While that would be better under low load, seems like it
> would be markedly worse under high load (ie, if someone
> actually is watching the stats constantly).

Only if "constantly" means "more than twice per second" does it get
worse than today (and of course assuming you run it in different
transactions, because it still caches the values inside a transaction
just as before).

I was considering implementing some sort of backoff ("already written
this half second, won't write a new one"), but I couldn't really come up
with a plausible scenario for it. For myself, even when I run a monitor
set to refresh often, that's set to once every 10 seconds - if it's
configged to do it "really often", that's once / second, which is still
better than before. And I'd not normally run it set that fast on a
system that's performance sensitive...

(And if I set it to > 1/0.5 sec I won't even get updated data on current
versions, whereas with this patch I do - at the expense of performance)

//Magnus

В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgstat: delayed write of stats file
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: LDAP lookup of connection parameters