On Fri, Sep 30, 2022 at 8:20 PM Andres Freund <and...@anarazel.de> wrote: > I think it'd be interesting to look at per-record-type stats between two > equivalent workload, to see where practical workloads suffer the most > (possibly with fpw=off, to make things more repeatable).
I would expect, and Dilip's results seem to confirm, the effect to be pretty uniform: basically, nearly every record gets bigger by 4 bytes. That's because most records contain at least one block reference, and if they contain multiple block references, likely all but one will be marked BKPBLOCK_SAME_REL, so we pay the cost just once. Because of alignment padding, the practical effect is probably that about half of the records get bigger by 8 bytes and the other half don't get bigger at all. But I see no reason to believe that things are any better or worse than that. Most interesting record types are going to contain some kind of variable-length payload, so the chances that a 4 byte size increase pushes you across a MAXALIGN boundary seem to be no better or worse than fifty-fifty. > I think it'd be an OK tradeoff to optimize WAL usage for a few of the worst to > pay off for 56bit relfilenodes. The class of problems foreclosed is large > enough to "waste" "improvement potential" on this. I thought about trying to buy back some space elsewhere, and I think that would be a reasonable approach to getting this committed if we could find a way to do it. However, I don't see a terribly obvious way of making it happen. Trying to do it by optimizing specific WAL record types seems like a real pain in the neck, because there's tons of different WAL records that all have the same problem. Trying to do it in a generic way makes more sense, and the fact that we have 2 padding bytes available in XLogRecord seems like a place to start looking, but the way forward from there is not clear to me. -- Robert Haas EDB: http://www.enterprisedb.com
