On Thu, Nov 05, 2026 at 12:17:42PM +0000, Bertrand Drouvot wrote: > Right, that's why the text refers specifically to the 256KB target. Do you > mean that the L2 cache rationale should be dropped now that it does not > necessarily apply to the resulting ring size?
v4 still has the same text: +For bulk reads, the requested ring size is at least 256KB. The 256KB target is +small enough to fit in L2 cache, which makes transferring pages from OS cache +to shared buffer cache efficient. L2 caches can be larger than 256kB, so having a larger size could still be effective. The current wording sounds slightly confusing to me here due to that. But perhaps your wording is fine enough. I suspect that Andres and other folks involved in this area of the code would have comments about these parts. Better to wait for inputs from them. > That makes sense. I've listed the commands under each applicable strategy. > Note > that some appear in both lists: for example, CREATE DATABASE uses bulkread for > the source and bulkwrite for the destination. I did not go as far as > explaining > why in the glossary. The checksumming part is missing for checksums where BAS_VACUUM is in use. v4-0002 seems mostly OK here, with your previous adjustments included. + <literal>vacuum</literal>: I/O operations performed using the + <literal>vacuum</literal> + <glossterm linkend="glossary-buffer-access-strategy">buffer access + strategy</glossterm> In v4-0003, too many vacuum references perhaps? This is the same as my previous comment when I have looked at the v3 series. I'm wondering if you should make it simpler, by the addition of linkend once within parenthesis like a simpler "(see also <linkend>BAS</>)", with a set of <literal>s for the follow-up references. -- Michael
signature.asc
Description: PGP signature
