On Thu, Aug 8, 2013 at 04:12:06PM -0500, Jon Nelson wrote:
> On Thu, Aug 8, 2013 at 2:50 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> > On 08/08/2013 05:28 PM, Jon Nelson wrote:
> ...
>
> > Just an idea - can you check if using a fillfactor different form 100
> > changes anything
> >
> > pgbench -s 20 -p 54320 -d pgb -F 90 -i
> >
> >
> >> pgbench -j 80 -c 80 -T 120 -p 54320 pgb
> >> pg_ctl -D tt -w stop
> >
> > That is, does extending tables and indexes to add updated tuples play
> > any role here
>
> I gave it a go - it didn't make any difference at all.
> 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. Should this feature be reconsidered?
How much slower would it be if we wrote it with zeros after
posix_fallocate() --- that would still give use single extents. Has
anyone tested to see if the write without test_fallocate() still gives
us one extent?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
