Hi, On 2022-10-10 08:10:22 -0400, Robert Haas wrote: > On Mon, Oct 10, 2022 at 5:16 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > I have also executed my original test after applying these patches on > > top of the 56 bit relfilenode patch. So earlier we saw the WAL size > > increased by 11% (66199.09375 kB to 73906.984375 kB) and after this > > patch now the WAL generated is 58179.2265625. That means in this > > particular example this patch is reducing the WAL size by 12% even > > with the 56 bit relfilenode patch. > > That's a very promising result, but the question in my mind is how > much work would be required to bring this patch to a committable > state?
The biggest part clearly is to review the variable width integer patch. It's not a large amount of code, but probably more complicated than average. One complication there is that currently the patch assumes: * Note that this function, for efficiency, reads 8 bytes, even if the * variable integer is less than 8 bytes long. The buffer has to be * allocated sufficiently large to account for that fact. The maximum * amount of memory read is 9 bytes. We could make a less efficient version without that assumption, but I think it might be easier to just guarantee it in the xlog*.c case. Using it in xloginsert.c is pretty darn simple, code-wise. xlogreader is bit harder, although not for intrinsic reasons - the logic underlying COPY_HEADER_FIELD seems unneccessary complicated to me. The minimal solution would likely be to just wrap the varint reads in another weird macro. Leaving the code issues themselves aside, one important thing would be to evaluate what the performance impacts of the varint encoding/decoding are as part of "full" server. I suspect it'll vanish in the noise, but we'd need to validate that. Greetings, Andres Freund
