On 2013-09-04 08:01:30 -0700, Jeff Davis wrote:
> On Thu, 2013-08-08 at 17:42 -0400, Tom Lane wrote:
> > Jon Nelson <jnelson+pgsql@jamponi.net> writes:
> > > At this point I'm convinced that the issue is a pathological case in
> > > ext4. The performance impact disappears as soon as the unwritten
> > > extent(s) are written to with real data. Thus, even though allocating
> > > files with posix_fallocate is - frequently - orders of magnitude
> > > quicker than doing it with write(2), the subsequent re-write can be
> > > more expensive. At least, that's what I'm gathering from the various
> > > threads. Why this issue didn't crop up in earlier testing and why I
> > > can't seem to make test_fallocate do it (even when I modify
> > > test_fallocate to write to the newly-allocated file in a mostly-random
> > > fashion) has me baffled.
> >
> > Does your test program use all the same writing options that the real
> > WAL writes do (like O_DIRECT)?
> >
> > > Should this feature be reconsidered?
> >
> > Well, ext4 isn't the whole world, but it's sure a big part of it.
> > The real point though is that obviously we didn't do enough performance
> > testing, so we'd better do more before deciding what to do.
>
> Greg Smith,
>
> Do you have some thoughts about this? More tests we should run? We may
> need to revert the patch.
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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services