Hi, On 2013-09-04 11:15:37 -0400, Stephen Frost wrote: > * Andres Freund (and...@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.
It does end up with larger extents. That's why e.g. several of the virtualization solutions do it for container files. I was sceptical of the idea of using fallocate() for WAL file allocation from the get go and voiced that repeatedly, but the argument was made that it's a convenient testcase to familiarize ourselves with fallocate(). As that argument won we should stick to it and learn the ropes. Part of that is zeroing, so we should do that. It's a single write() + error checking, so I don't really see much complexity that way. > One might ask why the kernel guys aren't doing this themselves or > figuring out why it's necessary to make it worthwhile. So, if I understood Ted correctly the reason it's slower is that fallocate() onl marks the extents as containing 'zero' without actually touching the data. When then a partial write into the area is done the rest of the page has to be actively zeroed on disk. I am not sure that explains all the slowdown, but given that according to tests published in this thread, the additional zeroing helps to get at the former + small win state... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers