Re: Problems with autovacuum

Список
Период
Сортировка
От Tom Lane
Тема Re: Problems with autovacuum
Дата
Msg-id 2917.1244492214@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problems with autovacuum  (Alvaro Herrera)
Ответы Re: Problems with autovacuum  (Alvaro Herrera)
Список pgsql-performance
Дерево обсуждения
Problems with autovacuum  (Łukasz Jagiełło, )
 Re: Problems with autovacuum  (Scott Marlowe, )
  Re: Problems with autovacuum  (Grzegorz Jaśkiewicz, )
   Re: Problems with autovacuum  (Scott Marlowe, )
   Re: Problems with autovacuum  (Łukasz Jagiełło, )
    Re: Problems with autovacuum  (Tom Lane, )
     Re: Problems with autovacuum  (Łukasz Jagiełło, )
     Re: Problems with autovacuum  (Alvaro Herrera, )
      Re: Problems with autovacuum  (Tom Lane, )
       Re: Problems with autovacuum  (Alvaro Herrera, )
        Re: Problems with autovacuum  (Tom Lane, )
         Re: Problems with autovacuum  (Alvaro Herrera, )
          Re: Problems with autovacuum  (Tom Lane, )
           Re: Problems with autovacuum  (Alvaro Herrera, )
            Re: Problems with autovacuum  (Tom Lane, )
             Re: Problems with autovacuum  (Scott Marlowe, )
             Re: Problems with autovacuum  (Alvaro Herrera, )
              Re: Problems with autovacuum  (Tom Lane, )
               Re: Problems with autovacuum  (Alvaro Herrera, )
                Re: Problems with autovacuum  (Alvaro Herrera, )
                Re: Problems with autovacuum  (Tom Lane, )
       Re: Problems with autovacuum  (Łukasz Jagiełło, )
  Re: Problems with autovacuum  (Łukasz Jagiełło, )
   Re: Problems with autovacuum  (Grzegorz Jaśkiewicz, )
Alvaro Herrera <> 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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Problems with autovacuum
Следующее
От: Віталій Тимчишин
Дата:
Сообщение: Re: Pointers needed on optimizing slow SQL statements