[Xapian-tickets] [Xapian] #348: Compress replication changesets
Xapian
nobody at xapian.org
Mon Feb 1 23:05:03 GMT 2010
#348: Compress replication changesets
---------------------------+------------------------------------------------
Reporter: olly | Owner: olly
Type: defect | Status: new
Priority: high | Milestone: 1.1.4
Component: Backend-Chert | Version: SVN trunk
Severity: normal | Keywords:
Blockedby: | Platform: All
Blocking: |
---------------------------+------------------------------------------------
Comment(by richard):
I'm not fully convinced that it's sensible to always compress the
changesets, though the argument about keeping the number of codepaths to a
minimum seems quite compelling, and I suspect it would be an improvement
in most cases. CPU doesn't seem likely to be the limiting factor when
applying changesets on the clients, but I've not enough evidence to be
sure about that either way.
Changesets already begin with a magic string to make the file easy to
identify, followed by an integer version number (currently 1), so there
would be no need to change the format on disk in a backwards incompatible
manner to support both compressed and non-compressed changesets here: we'd
just use version number 2 for compressed changesets. [The version numbers
were partly implemented with this in mind, and partly so that we could
support other schemes in future, such as storing the sequence of key-tag
operations involved in a changeset, rather than the block level changes.]
If we're willing to support a second codepath for non-compressed
changesets, we can punt this to 1.2.x. - we might need to leave
compression off by default until 1.3.x if we did this though, so that any
1.2.x client could read changesets from any 1.2.y server.
I'd be happy to live with this, in the interests of getting 1.2 out the
door.
--
Ticket URL: <http://trac.xapian.org/ticket/348#comment:4>
Xapian <http://xapian.org/>
Xapian
More information about the Xapian-tickets
mailing list