Re: Design proposal: fsync absorb linear slider

Поиск
Список
Период
Сортировка
От didier
Тема Re: Design proposal: fsync absorb linear slider
Дата
Msg-id CAJRYxu++4DGwwXdyvNKpZ6_TXQXcy1EL=46Ck3sz0HG86H_ELQ@mail.gmail.com
обсуждение исходный текст
Ответ на Design proposal: fsync absorb linear slider  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: Design proposal: fsync absorb linear slider  (Robert Haas <robertmhaas@gmail.com>)
Re: Design proposal: fsync absorb linear slider  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
Hi


On Tue, Jul 23, 2013 at 5:48 AM, Greg Smith <greg@2ndquadrant.com> wrote:
Recently I've been dismissing a lot of suggested changes to checkpoint fsync timing without suggesting an alternative.  I have a simple one in mind that captures the biggest problem I see:  that the number of backend and checkpoint writes to a file are not connected at all.

We know that a 1GB relation segment can take a really long time to write out.  That could include up to 128 changed 8K pages, and we allow all of them to get dirty before any are forced to disk with fsync.

It was surely already discussed but why isn't postresql  writing sequentially its cache in a temporary file? With storage random speed at least five to ten time slower it could help a lot.
Thanks

Didier

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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Adding Zigzag Merge Join to Index Nested Loops Join
Следующее
От: "MauMau"
Дата:
Сообщение: Re: install libpq.dll in bin directory on Windows / Cygwin