Horton

Re: Handing off SLRU fsyncs to the checkpointer

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>, Jakub Wartak <Jakub.Wartak@tomtom.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-08-26T18:09:50Z
Lists: pgsql-hackers 
On 2020-Aug-25, Andres Freund wrote:

> 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.

Hmm, including the sorted ItemId array in the WAL record might make
sense to alleviate the qsort work ...

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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