From: | Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #12071: Stat collector went crasy (50MB/s constant writes) |
Date: | 2014-11-27 10:26:32 |
Message-ID: | CAK-MWwSXXWFA-Rgpo9EE-cO+wCs=xDDjoJP9+P6RR1SY1HiWpQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
FWIW, I got curious and checked why we decided not to implement this
> while reworking the stats in 9.3, as keeping an is_dirty flag seems as a
> rather straightforward and simple optimization.
>
> Turns out it's actually considerably more complex, because one of the
> sources of statistics updates are (surprise surprise) autovacuum
> workers. So the whole flow may look like this (in >= 9.3):
>
> 1) launcher requests a fresh stats file (dbs list only)
> 2) worker is started for a particular DB (by launcher)
> 3) the worker requests a stats file (with details for the DB)
>
Now for (nearly) idle databases worker do nothing and simple exit in 99.9%.
And if there a lot of idle/low-active db's in cluster - is_dirty tracking
would be beneficial on both pre 9.3 and after 9.3 versions (and in 9.3+ it
will be especially effective because id_dirty tracked per-db basis).
Kind Regards,
Maksym
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2014-11-27 18:24:11 | Re: [BUGS] BUG #12071: Stat collector went crasy (50MB/s constant writes) |
Previous Message | Tommaso Sala | 2014-11-27 10:13:02 | Re: BUG #12053: Strange behavior for numeric types with unspecified precision-scale |
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2014-11-27 10:33:34 | Re: [v9.5] Custom Plan API |
Previous Message | Etsuro Fujita | 2014-11-27 10:22:03 | Re: inherit support for foreign tables |