Re: [PING] fallocate() causes btrfs to never compress postgresql files - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [PING] fallocate() causes btrfs to never compress postgresql files
Date
Msg-id CABUevExxDKNsnwJ_hmt7Y4k_0zjy6wMoqsTBAEUZix4EkKQvnA@mail.gmail.com
Whole thread Raw
In response to Re: [PING] fallocate() causes btrfs to never compress postgresql files  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers


On Fri, Jul 11, 2025 at 12:45 AM Thomas Munro <thomas.munro@gmail.com> wrote:
On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou <jimis@gmx.net> wrote:
> > I applied the patch on PostgreSQL v17 and am testing it now. I chose
> > ftruncate method and I see ftruncate in action using strace while doing
> > pg_restore of a big database. Nothing unexpected has happened so far. I also
> > verified that files are being compressed, obeying Btrfs's mount option
> > compress=zstd.
> >
> > Thanks for the patch! What are the odds of commiting it to v17?
>
> Ping. :-)
> Patch behaves good for me. Any chance of applying it and backporting it?

Yeah, this seems to make sense, as it is a pretty bad regression for
people who are counting on BTRFS compression for their large database.
Not so sure about the threshold bit -- I'd probably leave that out of
the backport in the interest of stable branch-minimalism.  Anyone have
any better ideas, better naming, or objections?

Not just to throw a wrench in there, but... Should this perhaps be a tablespace option? ISTM having different filesystems for them is a good reason to use tablespaces in the first place, and then being able to pick different options...

--

pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: Improve error reporting in 027_stream_regress test
Next
From: Dmitry
Date:
Subject: Re: IPC/MultixactCreation on the Standby server