From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndQuadrant(dot)com> |
Cc: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, 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-09-04 15:01:30 |
Message-ID: | 1378306890.23979.18.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2013-08-08 at 17:42 -0400, Tom Lane wrote:
> 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.
Greg Smith,
Do you have some thoughts about this? More tests we should run? We may
need to revert the patch.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-09-04 15:03:34 | Re: [v9.4] row level security |
Previous Message | Stephen Frost | 2013-09-04 15:01:19 | Re: [v9.4] row level security |