Re: 9.4 regression

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

In response to

Responses

Browse pgsql-hackers by date

  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