Hi,
Thanks for pushing! Sorry to not get around to a review before...
On 2021-01-15 11:42:50 +0900, Michael Paquier wrote:
> On Fri, Jan 15, 2021 at 03:25:24PM +1300, Thomas Munro wrote:
> > Thanks Michael! Another notch for the unnecessary system call
> > hitlist: https://wiki.postgresql.org/wiki/Syscall_Reduction
>
> A quick question. How much does it matter in terms of
> micro-performance for this code path depending on max/min_wal_size?
I can't see it being a problem here. Disision-by-non-constant is
expensive, but syscalls are more expensive. And journalled filesystem
operations like renames are *much* more expensive.
> Andres has mentioned its aio work, without telling any numbers.
I only found it while working on the AIO stuff, it's not really
dependant on it. I saw significant performance drops in the last part of
a checkpoint in both aio / master, but additional debugging output I had
in the aio branch made it obvious that it's not actuall the buffer sync
where the time is spent.
> "No backpatch is done per the lack of field complaints."
Because there's no real way to attribute the slowdown to WAL file
recycling in production workloads on master, I don't think we could
really expect field complaints. Everyone will just attribute the
slowdown to BufferSync() or file sync.
I think the way we currently emit WAL timings is quite quite
unhelpful. The fact that we attribute CheckpointWriteDelay() to the
write time makes it nearly useless until you're at the point the
checkpoint can't be completed in time. Similarly, the "sync" time"
covers many things that aren't syncing...
Greetings,
Andres Freund
