On Thu, Nov 11, 2021 at 12:29 AM Bossart, Nathan <bossartn@amazon.com> wrote:
>
> On 10/8/21, 1:55 PM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> > Here is a first attempt at adding the pre-allocation logic to the
> > checkpointer. I went ahead and just used CheckpointWriteDelay() for
> > pre-allocating during checkpoints. I've done a few pgbench runs, and
> > it seems to work pretty well. Initialization is around 15% faster,
> > and I'm seeing about a 5% increase in TPS with a simple-update
> > workload with wal_recycle turned off. Of course, these improvements
> > go away once segments can be recycled.
>
> Here is a rebased version of this patch set. I'm getting the sense
> that there isn't a whole lot of interest in this feature, so I'll
> likely withdraw it if it goes too much longer without traction.
As I mentioned in the other thread at [1], let's continue the discussion here.
Why can't the walwriter pre-allocate some of the WAL segments instead
of a new background process? Of course, it might delay the main
functionality of the walwriter i.e. flush and sync the WAL files, but
having checkpointer do the pre-allocation makes it do another extra
task. Here the amount of walwriter work vs checkpointer work, I'm not
sure which one does more work compared to the other.
Another idea could be to let walwrtier or checkpointer pre-allocate
the WAL files whichever seems free as-of-the-moment when the WAL
segment pre-allocation request comes. We can go further to let the
user choose which process i.e. checkpointer or walwrtier do the
pre-allocation with a GUC maybe?
[1] - https://www.postgresql.org/message-id/CALj2ACVqYJX9JugooRC1chb2sHqv-C9mYEBE1kxwn%2BTn9vY42A%40mail.gmail.com
Regards,
Bharath Rupireddy.