From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jerry Jelinek <jerry(dot)jelinek(at)joyent(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch to allow disable of WAL recycling |
Date: | 2018-07-16 13:19:25 |
Message-ID: | 20180716131925.4qbkizns2lrluiak@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-07-15 20:55:38 -0400, Tom Lane wrote:
> That's not the way to think about it. On a COW file system, we don't
> want to "create 16MB files" at all --- we should just fill WAL files
> on-the-fly, because the pre-fill activity isn't actually serving the
> intended purpose of reserving disk space. It's just completely useless
> overhead :-(. So we can't really make a direct comparison between the
> two approaches; there's no good way to net out the cost of constructing
> the WAL data we need to write.
We probably should still allocate them in 16MB segments. We rely on the
size being fixed in a number of places. But it's probably worthwhile to
just do a posix_fadvise or such. Also, if we continually increase the
size with each write we end up doing a lot more metadata transactions,
which'll essentially serve to increase journalling overhead further.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Muntyanu | 2018-07-16 13:21:14 | Re: Parallel queries in single transaction |
Previous Message | Andres Freund | 2018-07-16 13:13:37 | Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)" |