From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Andy Fan <zhihuifan1213(at)163(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Maxim Orlov <m(dot)orlov(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Pre-allocating WAL files |
Date: | 2025-01-21 16:13:14 |
Message-ID: | Z4_Hmj2R8NXnAI-K@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 21, 2025 at 09:52:51AM -0600, Nathan Bossart wrote:
> On Tue, Jan 21, 2025 at 03:31:27AM +0000, Andy Fan wrote:
>> 3. Why is the purpose of preallocated_segments directory? what in my
>> mind is we just prellocate the normal filename so that XLogWrite could
>> open it directly. This is same as what wal_recycle does and we can reuse
>> the same strategy to clean up them if they are not needed anymore.
>
> The purpose is to limit the use of pre-allocated segments to only
> situations where WAL recycling is not sufficient. Basically, if writing a
> record would require a new segment to be created, we can quickly pull a
> pre-allocated one instead of creating it ourselves. Besides simplifying
> matters, this prevents a lot of unnecessary pre-allocation, since many
> workloads will almost never need anything beyond the recycled segments.
That being said, it would be nice to avoid the fsync() overhead to move a
pre-allocated WAL into place. My first instinct is that would be
substantially more complicated and may not actually improve matters all
that much, but I agree that it's worth exploring.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2025-01-21 16:21:58 | Re: Statistics Import and Export |
Previous Message | Benoit Lobréau | 2025-01-21 16:01:06 | doc: explain pgstatindex fragmentation |