From: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
---|---|
To: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Subject: | Re: 9.4 regression |
Date: | 2013-08-08 21:12:06 |
Message-ID: | CAKuK5J0s9ZikBxUTdLW4zF=yXYrBzk0WwiM=-fX_xJ3Hes5jrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 8, 2013 at 2:50 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)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?
--
Jon
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-08-08 21:24:26 | Re: 9.4 regression |
Previous Message | Hannu Krosing | 2013-08-08 19:50:33 | Re: 9.4 regression |