On Wed, Sep 4, 2013 at 11:26 AM, Tom Lane <[email protected]> wrote: > Stephen Frost <[email protected]> writes: >> * Andres Freund ([email protected]) 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
