Date: Tue, 24 Oct 2023 20:54:01 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	Andres Freund <andres@anarazel.de>,
	Dilip Kumar <dilipbalaut@gmail.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org,
	Masahiko Sawada <sawada.mshk@gmail.com>
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when
 possible
Message-ID: <20231025015401.GB977906@nathanxps13>
References: <CALj2ACXUbvON86vgwTkum8ab3bf1=HkMxQ5hZJZS3ZcJn8NEXQ@mail.gmail.com>
 <CAFiTN-uCG-+axA4r02_9OYgKJU_GkJ1=tBCxq_5UvyWmWEBywA@mail.gmail.com>
 <CALj2ACU9cfAcfVsGwUqXMace_7rfSBJ7+hXVJfVV1jnspTDGHQ@mail.gmail.com>
 <628b07b79743e2614ab1724f516cbd41560d6551.camel@j-davis.com>
 <20230114203403.4zpg72fw2qb34awf@awork3.anarazel.de>
 <0d84c025e38673cb575dcf4987d050fe7b1e1a1f.camel@j-davis.com>
 <20231011224353.cl7c2s222dw3de4j@awork3.anarazel.de>
 <CALj2ACU2DGH-BB_187N7gfVkLdxfJ+doVTcteS0ugLn_c8mLOw@mail.gmail.com>
 <CALj2ACVgVgA5BSSrEYO2eTMEGB=QUbcYosYm3vZ3R2=GPB6tNw@mail.gmail.com>
 <5c6e8e60c5c156a9f51ccf850f70829e45a985a1.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5c6e8e60c5c156a9f51ccf850f70829e45a985a1.camel@j-davis.com>
Archived-At: <https://www.postgresql.org/message-id/20231025015401.GB977906%40nathanxps13>
Precedence: bulk

On Tue, Oct 24, 2023 at 05:15:19PM -0700, Jeff Davis wrote:
> * Are you sure that reducing the number of calls to memcpy() is a win?
> I would expect that to be true only if the memcpy()s are tiny, but here
> they are around XLOG_BLCKSZ. I believe this was done based on a comment
> from Nathan Bossart, but I didn't really follow why that's important.
> Also, if we try to use one memcpy for all of the data, it might not
> interact well with my idea above to avoid taking the lock.

I don't recall exactly why I suggested this, but if additional memcpy()s
help in some way and don't negatively impact performance, then I retract my
previous comment.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com