Re: 9.4 regression

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, 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>
Subject: Re: 9.4 regression
Date: 2013-09-04 15:26:59
Message-ID: 2781.1378308419@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
>> I'd vote for adding zeroing *after* the fallocate() first. That's what's
>> suggested by kernel hackers and what several other large applications
>> do. As it looks like it's what we would have to do if we ever get to use
>> fallocate for relation extension where we would have actual benefits
>> from it.

> Does that actually end up doing anything different from what we were
> doing pre-patch here? At best, it *might* end up using a larger extent,
> but unless we can actually be confident that it does, I'm not convinced
> the additional complexity is worth it and would rather see this simply
> reverted.

> One might ask why the kernel guys aren't doing this themselves or
> figuring out why it's necessary to make it worthwhile.

The larger picture is that that isn't the committed behavior,
but a different one, one which would need performance testing.

At this point, I vote for reverting the patch and allowing it to be
resubmitted for a fresh round of testing with the zeroing added.
And this time we'll need to do the testing more carefully.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2013-09-04 15:28:59 Re: [v9.4] row level security
Previous Message Kevin Grittner 2013-09-04 15:24:11 Re: [v9.4] row level security