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.mu...@gmail.com> wrote: > On Fri, Apr 26, 2024 at 4:37 AM Riku Iki <riku.ik...@gmail.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. >
