On Wed, Sep 4, 2013 at 11:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Andres Freund (andres@2ndquadrant.com) wrote:
>>> I'd vote for adding zeroing *after* the fallocate() first. That's what's
>>> suggested by kernel hackers and what several other large applications
>>> do. As it looks like it's what we would have to do if we ever get to use
>>> fallocate for relation extension where we would have actual benefits
>>> from it.
>
>> Does that actually end up doing anything different from what we were
>> doing pre-patch here? At best, it *might* end up using a larger extent,
>> but unless we can actually be confident that it does, I'm not convinced
>> the additional complexity is worth it and would rather see this simply
>> reverted.
>
>> One might ask why the kernel guys aren't doing this themselves or
>> figuring out why it's necessary to make it worthwhile.
>
> The larger picture is that that isn't the committed behavior,
> but a different one, one which would need performance testing.
>
> At this point, I vote for reverting the patch and allowing it to be
> resubmitted for a fresh round of testing with the zeroing added.
> And this time we'll need to do the testing more carefully.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company