> Da: Simon Riggs <si...@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
commitlog_lessbytes01.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
