Re: autovacuum stress-testing our system
Tomas Vondra <tv@fuzzy.cz>
From: Tomas Vondra <tv@fuzzy.cz>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-09-26T15:35:02Z
Lists: pgsql-hackers
Dne 26.09.2012 17:29, Alvaro Herrera napsal: > Excerpts from Tomas Vondra's message of mié sep 26 12:25:58 -0300 > 2012: >> Dne 26.09.2012 16:51, Jeff Janes napsal: > >> > I think forking it off to to another value would be better. If >> you >> > are an autovacuum worker which is just starting up and so getting >> its >> > initial stats, you can tolerate a stats file up to >> > "autovacuum_naptime >> > / 5.0" stale. If you are already started up and are just about to >> > vacuum a table, then keep the staleness at PGSTAT_RETRY_DELAY as >> it >> > currently is, so as not to redundantly vacuum a table. >> >> I always thought there's a "no more than one worker per database" >> limit, > > There is no such limitation. OK, thanks. Still, reading/writing the small (per-database) files would be much faster so it would be easy to read/write them more often on demand. Tomas
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Split pgstat file in smaller pieces
- 187492b6c2e8 9.3.0 cited