MIME-Version: 1.0
References: <CAMazQQfp+3f8tD_Q23rCR=O+Jj4jouSRVigbD8OmrTOfHV+8gA@mail.gmail.com>
In-Reply-To: <CAMazQQfp+3f8tD_Q23rCR=O+Jj4jouSRVigbD8OmrTOfHV+8gA@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Fri, 26 Apr 2024 09:25:03 +1200
Message-ID: <CA+hUKGLu-oDokjt=Hyb8cLPTm19s5HZSq0PY-jXBP6-u2cqMEg@mail.gmail.com>
Subject: Re: Preallocation changes in Postgresql 16
To: Riku Iki <riku.iki.x@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKGLu-oDokjt%3DHyb8cLPTm19s5HZSq0PY-jXBP6-u2cqMEg%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 26, 2024 at 4:37=E2=80=AFAM Riku Iki <riku.iki.x@gmail.com> wro=
te:
> I am wondering if there were preallocation related changes in PG16, and i=
f it is possible to disable preallocation in PostgreSQL 16?

I have no opinion on the btrfs details, but I was wondering if someone
might show up with a system that doesn't like that change.  Here is a
magic 8, tuned on "some filesystems":

        /*
         * If available and useful, use posix_fallocate() (via
         * FileFallocate()) to extend the relation. That's often more
         * efficient than using write(), as it commonly won't cause the ker=
nel
         * to allocate page cache space for the extended pages.
         *
         * However, we don't use FileFallocate() for small extensions, as i=
t
         * defeats delayed allocation on some filesystems. Not clear where
         * that decision should be made though? For now just use a cutoff o=
f
         * 8, anything between 4 and 8 worked OK in some local testing.
         */
        if (numblocks > 8)

I wonder if it wants to be a GUC.