| From: | Dimitrios Apostolou <jimis(at)gmx(dot)net> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Subject: | Re: [PING] fallocate() causes btrfs to never compress postgresql files |
| Date: | 2025-07-10 17:39:10 |
| Message-ID: | 98daac7f-a351-def2-bc36-7538c996ff51@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 12 Jun 2025, Dimitrios Apostolou wrote:
> On Mon, 9 Jun 2025, Thomas Munro wrote:
>
>> On Tue, Jun 3, 2025 at 1:58 AM Dimitrios Apostolou <jimis(at)gmx(dot)net> wrote:
>>> This sounds like the best solution IMO. People can then experiment with
>>> different settings and filesystems, and that way we also learn in the
>>> process. Thank you for the effort and patches so far.
>>
>> OK, here's a basic patch to experiment with. You can set:
>>
>> file_extend_method = fallocate,ftruncate,write
>> file_extend_method_threshold = 8 # (below 8 always write, 0 means never
>> write)
>>
>
> 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?
>
> Dimitris
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florents Tselai | 2025-07-10 17:41:11 | Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part |
| Previous Message | Tom Lane | 2025-07-10 17:38:40 | Re: pg_dump sort priority mismatch for large objects |