From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | Hannu Krosing <hannu(at)2ndquadrant(dot)com>, 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:42:02 |
Message-ID: | 8037.1375998122@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jon Nelson <jnelson+pgsql(at)jamponi(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-08-08 21:46:18 | Re: 9.4 regression |
Previous Message | Jon Nelson | 2013-08-08 21:33:05 | Re: 9.4 regression |