Re: Handing off SLRU fsyncs to the checkpointer

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Jakub Wartak <Jakub.Wartak@tomtom.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-08-26T05:20:59Z
Lists: pgsql-hackers
Hi,

On 2020-08-26 15:58:14 +1200, Thomas Munro wrote:
> >                 --12.51%--compactify_tuples
> >                           PageRepairFragmentation
> >                           heap2_redo
> >                           StartupXLOG
> 
> I wonder if there is something higher level that could be done to
> reduce the amount of compaction work required in the first place, but
> in the meantime I'm very happy if we can improve the situation so much
> with such a microscopic improvement that might eventually benefit
> other sorting stuff...

Another approach could be to not perform any sorting during recovery,
instead including enough information in the WAL record to avoid doing a
full blown PageRepairFragmentation during recovery.

Greetings,

Andres Freund



Commits

  1. Remove unused function prototypes.

  2. Defer flushing of SLRU files.

  3. Improve the vacuum error context phase information.

  4. Cache smgrnblocks() results in recovery.

  5. Refactor the fsync queue for wider use.

  6. Increase maximum number of clog buffers.

  7. Make the number of CLOG buffers adaptive, based on shared_buffers.

  8. Replace implementation of pg_log as a relation accessed through the