Date: Thu, 27 Aug 2020 16:28:54 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
	Sait Talha Nisanci <Sait.Nisanci@microsoft.com>,
	Thomas Munro <thomas.munro@gmail.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	Dmitry Dolgov <9erthalion6@gmail.com>,
	David Steele <david@pgmasters.net>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [EXTERNAL] Re: WIP: WAL prefetch (another approach)
Message-ID: <20200827202853.GT29590@tamriel.snowman.net>
References: <20200827182642.GO29590@tamriel.snowman.net>
 <6B918AFB-88D6-4687-8B4A-34C472E48BF4@anarazel.de>
 <20200827185116.GQ29590@tamriel.snowman.net>
 <CA+TgmoYSnACj2ouDKVO+vJ=3r_=ChhmE2mvy2DGOKbpDeTYG+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="3BIcke/FEyR2Oz6k"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoYSnACj2ouDKVO+vJ=3r_=ChhmE2mvy2DGOKbpDeTYG+Q@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--3BIcke/FEyR2Oz6k
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Aug 27, 2020 at 2:51 PM Stephen Frost <sfrost@snowman.net> wrote:
> > > Hm? At least earlier versions didn't do prefetching for records with =
an fpw, and only for subsequent records affecting the same or if not in s_b=
 anymore.
> >
> > We don't actually read the page when we're replaying an FPW though..?
> > If we don't read it, and we entirely write the page from the FPW, how is
> > pre-fetching helping..?
>=20
> Suppose there is a checkpoint. Then we replay a record with an FPW,
> pre-fetching nothing. Then the buffer gets evicted from
> shared_buffers, and maybe the OS cache too. Then, before the next
> checkpoint, we again replay a record for the same page. At this point,
> pre-fetching should be helpful.

Sure- but if we're talking about 25GB of WAL, on a server that's got
32GB, then why would those pages end up getting evicted from memory
entirely?  Particularly, enough of them to end up with such a huge
difference in replay time..

I do agree that if we've got more outstanding WAL between checkpoints
than the system's got memory then that certainly changes things, but
that wasn't what I understood the case to be here.

> Admittedly, I don't quite understand whether that is what is happening
> in this test case, or why SDD vs. HDD should make any difference. But
> there doesn't seem to be any reason why it doesn't make sense in
> theory.

I agree that this could be a reason, but it doesn't seem to quite fit in
this particular case given the amount of memory and WAL.  I'm suspecting
that it's something else and I'd very much like to know if it's a
general "this applies to all (most?  a lot of?) SSDs because the
hardware has a larger than 8KB page size and therefore the kernel has to
read it", or if it's something odd about this particular system and
doesn't apply generally.

Thanks,

Stephen

--3BIcke/FEyR2Oz6k
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJfSBeFAAoJEO1sijiDR2RVVWsQAI5S52AWm2iQ5Bzj/LYTAyz/
4tAwWiybnANZ6l8Fw877L8ARtPYcVQK+DTE4ReHbzMkHMgAO687llAJGfuJD74RQ
I07dhiyyPQEHdHcqEcjdnc4xnvYoWtUaHhxM9+h8NsoWPdQjc/01AKzlnMXjCNdV
IFLKuVb/vQr2iFFPFCTn+gfPzk22OcW4PtPnA1T6MsbeeR8jxWdVmW8+f9SD8zpl
s5I5rZ/XhAOIFq2ov42BuZ7lNGdBWJFIwuC8hkxOcv11l88zpccC3WG+6plYp+Sx
JjP2PCZIg/3KQzfw0i7ke7D6bQcxdmbXPDoEk2TwCYTlPAJaNeslLyZrLTm+zUMF
7W+WdY+tvkVynFQxHCJwSZZ193lwABpd/y6qMDvu1PQ3LfTbN57lRRCEZLOJDI48
M6l+u/diy1+q7oNb25NIQN5l7H4ij296ZzWny+BYqkmkS26tMN6u499E2YyvydWb
/Sima6jYbX+mw7iGHItc56UarON310QhmYBr4kxLUdJOJ5uTnF6nLe0YB3h8gJ49
3s9Nm8XZMzocb9yUEDHuaFAUuMBrC65ZJeecWzOE42OeiqsMHOolYsZJmkgZpy3N
WaIpBIiaelknnQySTaUbI2GdBrQz1fvMrAciMmDD6+FhT3LcJgd8x44vzkNaPIzk
PmSJTVbpjlJtOc5V36MI
=6aRI
-----END PGP SIGNATURE-----

--3BIcke/FEyR2Oz6k--