Re: use less space in xl_xact_commit patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Leonardo Francalanci <m_lists(at)yahoo(dot)it>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: use less space in xl_xact_commit patch
Date: 2011-05-25 19:13:44
Message-ID: BANLkTiksv-spVxFeLUzAs=jRTVzF0B3WUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 25, 2011 at 10:41 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> OK, thats clear. Thanks.
>
> That formatting sounds quite complex.
>
> I would propose we split this into 2 WAL records: xl_xact_commit and
> xl_xact_commit_with_info
>
> xl_xact_commit doesn't have any flags, counts or arrays.
>
> xl_xact_commit_with_info always has all 3 counts, even if zero.
> Arrays follow the main record
>
> I think it might also be possible to removed dbId and tsId from
> xl_act_commit if we use that definition.

That's an interesting idea. I hadn't noticed that if nmsgs=0 then
those fields aren't needed either. Also, both nrels>0 and nmsgs>0
will probably only happen if some DDL has been done, which most
transactions probably don't, so it would be logical to have one record
type that excludes nrels, nmsgs, dbId, tsId, and another record type
that includes all of those. In fact, we could probably throw in xinfo
as well: if there's no DDL involved, we shouldn't need to set
XACT_COMPLETION_UPDATE_RELCACHE_FILE or
XACT_COMPLETION_FORCE_SYNC_COMMIT either.

But I'm not so sure about nsubxacts. It seems to me that we might
lose a lot of the benefit of having two record types if we have to use
the larger one whenever nsubxacts>0. I'm not exactly sure how common
subtransactions are, but if I had to guess I'd speculate that they are
far more frequent than DDL operations. Maybe we should think about
making the xl_xact_commit record contain just xact_time, nsubxacts,
and a subxact array; and then have the xl_xact_commit_with_info (or
maybe xl_xact_commit_full, or whatever we decide to call it) contain
everything else. That would shave off 20 bytes from the commit
records of any non-DDL operation, which would be pretty nice.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2011-05-25 19:14:06 Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Previous Message Peter Eisentraut 2011-05-25 19:07:45 Re: pg_upgrade automatic testing