From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: smgrzeroextend clarification |
Date: | 2023-05-12 23:24:19 |
Message-ID: | EDFBDEDD-4BC4-4CD9-B2C7-F721FF4D0BE7@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On May 12, 2023 11:36:23 AM PDT, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>Just a thought: should RelationCopyStorageUsingBuffer(), the new code
>used by CREATE DATABASE with the default strategy WAL_LOG, use the
>newer interface so that it creates fully allocated files instead of
>sparse ones?
I played with that, but at least on Linux with ext4 and xfs it was hard to find cases where it really was beneficial. That's actually how I ended up finding the issues I'd fixed recently-ish.
I think it might be different if we had an option to not use a strategy for the target database - right now we IIRC write back due to ring replacement. Entirely or largely in order, which I think removes most of the issues you could have.
One issue is that it'd be worse on platforms / filesystems without fallocate support, because we would write the data back twice (once with zeros, once the real data). Perhaps we should add a separate parameter controlling the fallback behaviour.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2023-05-12 23:47:56 | Re: [PATCHES] Post-special page storage TDE support |
Previous Message | Thomas Munro | 2023-05-12 23:01:49 | Re: Large files for relations |