Re: autovacuum stress-testing our system
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tomas Vondra <tv@fuzzy.cz>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-09-27T20:06:56Z
Lists: pgsql-hackers
On 27 September 2012 15:57, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Excerpts from Simon Riggs's message of jue sep 27 06:51:28 -0300 2012: >> On 26 September 2012 15:47, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> > >> > Really, as far as autovacuum is concerned, it would be much more useful >> > to be able to reliably detect that a table has been recently vacuumed, >> > without having to request a 10ms-recent pgstat snapshot. That would >> > greatly reduce the amount of time autovac spends on pgstat requests. >> >> VACUUMing generates a relcache invalidation. Can we arrange for those >> invalidations to be received by autovac launcher, so it gets immediate >> feedback of recent activity without polling? > > Hmm, this is an interesting idea worth exploring, I think. Maybe we > should sort tables in the autovac worker to-do list by age of last > invalidation messages received, or something like that. Totally unclear > on the details, but as I said, worth exploring. Just put them to back of queue if an inval is received. There is already support for listening and yet never generating to relcache inval messages. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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