From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Riku Iki <riku(dot)iki(dot)x(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Preallocation changes in Postgresql 16 |
Date: | 2024-04-25 21:25:03 |
Message-ID: | CA+hUKGLu-oDokjt=Hyb8cLPTm19s5HZSq0PY-jXBP6-u2cqMEg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | yudhi s | 2024-04-26 06:00:34 | Re: How you make efficient design for CDC and book marking |
Previous Message | Lok P | 2024-04-25 20:25:49 | How you make efficient design for CDC and book marking |