> Da: Simon Riggs <simon@2ndQuadrant.com>
> I can't find a clear discussion of what you are trying to do, and how,
> just a URL back to a complex discussion on another topic.
While trying to write a patch to allow changing an unlogged table into
a logged one, I had to add another int field to xl_xact_commit.
Robert Haas said:
"I have to admit I don't like this approach very much. I can't see
adding 4 bytes to every commit record for this feature."
which is a correct remark.
xl_xact_commit can contain some arrays (relation to drops,
committed sub-trans, shared invalidation msgs). The length of
these arrays is specified using 3 ints in the struct.
So, to avoid adding more ints to the struct, I've been suggested to
remove all the ints, and use xl_xact_commit.xinfo to flag which
arrays are, in fact, present.
So the whole idea is:
- remove nrels, nsubxacts and nmsgs from xl_xact_commit
- use bits in xinfo to signal which arrays are present at the end
of xl_xact_commit
- for each present array, add the length of the array (as int) at
the end of xl_xact_commit
- add each present array after all the lengths
> I can't see any analysis that shows whether this would be effective in
> reducing space of WAL records and what the impacts might be.
The space of WAL records should always be <= than without the patch:
in the worst case scenario, all ints are present (as they would without
the patch). In the best case, which I guess is the more common, each
xl_xact_commit will be 3 ints shorter.
I don't think the effect will be "perceivable": the whole idea is to allow
more variable-length structures in xl_xact_commit in the future,
without incrementing the space on disk.
> The patch contains very close to zero comments.
I tried to add some.
Leonardo
