Re: pgstat: delayed write of stats file - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: pgstat: delayed write of stats file
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA3525A@algol.sollentuna.se
Whole thread Raw
In response to pgstat: delayed write of stats file  ("Magnus Hagander" <mha@sollentuna.net>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgstat: delayed write of stats file
Next
From: "Albe Laurenz"
Date:
Subject: Re: LDAP lookup of connection parameters