Re: fallocate / posix_fallocate for new WAL file creation (etc...) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Date
Msg-id CA+TgmoYjkHh1+QV48q9orWc8APwEYK-6LHFyubsLtG-BFC5MnA@mail.gmail.com
Whole thread Raw
In response to Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: fallocate / posix_fallocate for new WAL file creation (etc...)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Support for RANGE ... PRECEDING windows in OVER
Next
From: Andres Freund
Date:
Subject: Re: extensible external toast tuple support