Re: patch to allow disable of WAL recycling

On Fri, Jul 6, 2018 at 3:37 AM, Jerry Jelinek <jerry.jelinek@joyent.com>
wrote:
>> If the problem is specifically the file system caching behavior, then we
>> could also consider using the dreaded posix_fadvise().
>
> I'm not sure that solves the problem for non-cached files, which is where
> we've observed the performance impact of recycling, where what should be a
> write intensive workload turns into a read-modify-write workload because
> we're now reading an old WAL file that is many hours, or even days, old
and
> has thus fallen out of the memory-cached data for the filesystem. The disk
> reads still have to happen.

What ZFS record size are you using?  PostgreSQL's XLOG_BLCKSZ is usually
8192 bytes.  When XLogWrite() calls write(some multiple of XLOG_BLCKSZ), on
a traditional filesystem the kernel will say 'oh, that's overwriting whole
pages exactly, so I have no need to read it from disk' (for example in
FreeBSD ffs_vnops.c ffs_write() see the comment "We must peform a
read-before-write if the transfer size does not cover the entire buffer").
I assume ZFS has a similar optimisation, but it uses much larger records
than the traditional 4096 byte pages, defaulting to 128KB.  Is that the
reason for this?

-- 
Thomas Munro
http://www.enterprisedb.com