Re: Preallocation changes in Postgresql 16

Thank you, I have such a system. I think my task would be to compile PG
from sources(need to learn this), and see how it works with and without
that code block.

On Thu, Apr 25, 2024 at 2:25 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:

> On Fri, Apr 26, 2024 at 4:37 AM Riku Iki <riku(dot)iki(dot)x(at)gmail(dot)com> wrote:
> > I am wondering if there were preallocation related changes in PG16, and
> if 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
> kernel
> * to allocate page cache space for the extended pages.
> *
> * However, we don't use FileFallocate() for small extensions, as
> it
> * defeats delayed allocation on some filesystems. Not clear where
> * that decision should be made though? For now just use a cutoff
> of
> * 8, anything between 4 and 8 worked OK in some local testing.
> */
> if (numblocks > 8)
>
> I wonder if it wants to be a GUC.
>