From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Maxim Orlov <m(dot)orlov(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Pre-allocating WAL files |
Date: | 2021-10-06 16:31:42 |
Message-ID: | 60A38487-AE37-4B57-8980-FB52D153A68B@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/6/21, 5:20 AM, "Maxim Orlov" <m(dot)orlov(at)postgrespro(dot)ru> wrote:
> We've looked through the code and everything looks good except few minor things:
> 1). Using dedicated bg worker seems not optimal, it introduces a lot of redundant code for little single action.
> We'd join initial proposal of Andres to implement it as an extra fuction of checkpointer.
Thanks for taking a look!
I have been thinking about the right place to put this logic. My
first thought is that it sounds like something that ought to go in the
WAL writer process, but as Andres noted upthread, that is undesirable
because it'll add latency for asynchronous commits. The checkpointer
process seems to be another candidate, but I'm not totally sure how
it'll fit in. My patch works by maintaining a small pool of pre-
allocated segments that is quickly replenished whenever one is used.
If the checkpointer is spending most of its time checkpointing, this
small pool could remain empty for long periods of time. To keep pre-
allocating WAL while we're checkpointing, perhaps we could add another
function like CheckpointWriteDelay() that is called periodically.
There still might be several operations in CheckPointGuts() that take
a while and leave the segment pool empty, but maybe that's okay for
now.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-10-06 16:43:05 | Re: Parallel vacuum workers prevent the oldest xmin from advancing |
Previous Message | Mark Dilger | 2021-10-06 16:25:49 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |