Re: fallocate / posix_fallocate for new WAL file creation (etc...)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Дата
Msg-id CA+TgmoYjkHh1+QV48q9orWc8APwEYK-6LHFyubsLtG-BFC5MnA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
On Mon, Jul 1, 2013 at 2:17 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Tue, 2013-07-02 at 02:13 +0900, Fujii Masao wrote:
>> Even in that case, if a user can easily know which platform posix_fallocate
>> should be used in, we can commit the patch with the configurable GUC
>> parameter.
>
> I disagree here. We're not talking about a huge win; this speedup may
> not even be detectable on a running system.
>
> I think Robert summarized the reason for the patch best: "I mean, if
> posix_fallocate() is faster, then it's just faster, right?". But if we
> need a new GUC, and DBAs now have one more thing they need to test about
> their platform, then that argument goes out the window.

Yeah.  If the patch isn't going to be a win on RHEL 5, I'd consider
that a good reason to scrap it for now and revisit it in 3 years.
There are still a LOT of people running RHEL 5, and the win isn't big
enough to engineer a more complex solution.  But ultimately RHEL 5,
like any other old system, will go away.

However, Greg's latest testing results seem to show that there isn't
much to worry about, so we may be fine anyway.

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



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Support for RANGE ... PRECEDING windows in OVER
Следующее
От: Andres Freund
Дата:
Сообщение: Re: extensible external toast tuple support