From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Tomas Vondra <tv(at)fuzzy(dot)cz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: autovacuum stress-testing our system |
Date: | 2012-09-27 20:06:56 |
Message-ID: | CA+U5nMJpa2FVUVa0wwjnK1nEZ42u+TiQvT5nZd0Q51FAVGRm-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27 September 2012 15:57, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-09-27 20:08:55 | Re: Oid registry |
Previous Message | Karl O. Pinc | 2012-09-27 20:06:16 | Re: psql, remove include of psqlscan.c |