Re: Problems with autovacuum

Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Problems with autovacuum
Дата
Msg-id 20090526235154.GO32650@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Problems with autovacuum  (Tom Lane)
Ответы Re: Problems with autovacuum  (Tom Lane)
Список 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, )
Tom Lane escribió:
> Alvaro Herrera <> writes:
> > Tom Lane escribi�:
> >> Hmm, maybe we need to improve the code too.  This example suggests that
> >> there needs to be some limit on the worker launch rate, even if there
> >> are so many databases that that means we don't meet naptime exactly.
>
> > We already have a 100ms lower bound on the sleep time (see
> > launcher_determine_sleep()).  Maybe that needs to be increased?
>
> Maybe.  I hesitate to suggest a GUC variable ;-)

Heh :-)

> One thought is that I don't trust the code implementing the minimum
> too much:
>
>     /* 100ms is the smallest time we'll allow the launcher to sleep */
>     if (nap->tv_sec <= 0 && nap->tv_usec <= 100000)
>     {
>         nap->tv_sec = 0;
>         nap->tv_usec = 100000;    /* 100 ms */
>     }
>
> What would happen if tv_sec is negative and tv_usec is say 500000?
> Maybe negative tv_sec is impossible here, but ...

I don't think it's possible to get negative tv_sec here currently, but
perhaps you're right that we could make this code more future-proof.

However I think there's a bigger problem here, which is that if the user
has set naptime too low, i.e. to a value lower than
number-of-databases * 100ms, we'll be running the (expensive)
rebuild_database_list function on each iteration ... maybe we oughta put
a lower bound on naptime based on the number of databases to avoid this
problem.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

Предыдущее
От: Alex Adriaanse
Дата:
Сообщение: Re: Hosted servers with good DB disk performance?
Следующее
От: "ramasubramanian"
Дата:
Сообщение: Bytea updation