Re: CLOG extension

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: CLOG extension
Дата
Msg-id CA+TgmobixPF1d3HD2dyyLOJ1CRfnLiZDK2AoJu9XgzfXXz_AMw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CLOG extension  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: CLOG extension  (Daniel Farina <daniel@heroku.com>)
Re: CLOG extension  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Thu, May 3, 2012 at 3:20 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Your two paragraphs have roughly opposite arguments...
>
> Doing it every 32 pages would give you 30 seconds to complete the
> fsync, if you kicked it off when half way through the previous file -
> at current maximum rates. So there is utility in doing it in larger
> chunks.

Maybe, but I'd like to try changing one thing at a time.  If we change
too much at once, it's likely to be hard to figure out where the
improvement is coming from.  Moving the task to a background process
is one improvement; doing it in larger chunks is another.  Those
deserve independent testing.

> If it is too slow, we would just wait for sync like we do now.
>
> I think we need another background process since we have both cleaning
> and pre-allocating tasks to perform.

Possibly.  I have some fear of ending up with too many background
processes, but we may need them.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: james
Дата:
Сообщение: Re: Have we out-grown Flex?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Advisory locks seem rather broken