On Mon, Jul 1, 2013 at 2:17 PM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
