| 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: | Whole Thread | Raw Message | 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 |