From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Łukasz Jagiełło <lukasz(dot)jagiello(at)gforces(dot)pl>, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Problems with autovacuum |
Date: | 2009-06-08 20:16:54 |
Message-ID: | 2917.1244492214@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I've been giving this some thought and tried several approaches. In the
> end the one that I like the most is raising autovacuum_naptime to a
> reasonable value for the exiting number of databases. The only problem
> I have with it is that it's trivial to change it in the autovacuum
> launcher process and have it stick, but there's no way to propagate the
> value out to backends or postmaster to that they SHOW the actual value
> in use by the launcher. The best I can do is emit a WARNING with the
> new value.
Well, that code isn't even correct I think; you're not supposed to
modify a GUC variable directly. I think you should just silently
use a naptime of at least X without changing the nominal GUC variable.
And definitely without the WARNING --- that's nothing but log spam.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Віталій Тимчишин | 2009-06-09 06:58:51 | Re: Pointers needed on optimizing slow SQL statements |
Previous Message | Alvaro Herrera | 2009-06-08 19:36:42 | Re: Problems with autovacuum |