Maxim Boguk wrote:
> It not happened before because just few weeks ago development process had
> been switched from single shared developer db to the private db's for each
> developer (so amount of databases increased from few to 10).
>
> PS: 10ms acceptable lag for autovacuum reading pgstat.tmp looks too strong
> limitation for me.
> I think it should be something like min(autovacuum_naptime/2,
> PGSTAT_RETRY_DELAY)
The issue is avoiding repeated vacuuming of the same table by two
different workers. I have thought sometimes that this concern is
overblown, and maybe we could use a different approach.
For example, one idea is to have the autovac worker sleep for some time
before vacuuming each table, to give pgstat time to catch up in case
someone else vacuumed the table concurrently. One issue with this is
that sleeping for too long would cause each worker run to take longer.
(But then workers already sleep due to cost_delay, so perhaps this is
not a serious problem).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
