[Xapian-devel] goodbye QuartzBufferedTable

Olly Betts olly at survex.com
Fri Aug 13 22:04:25 BST 2004


On Fri, Aug 13, 2004 at 07:56:42PM +0100, Sam Liddicott wrote:
> Whoa! Stop there. This is exciting. You are getting 160 documents per 
> second even with half a million in the index?

Yes.  160/sec was sustained until around 600K docs, then it started to
tail off a little.  Currently it's doing 110/sec with 1800K docs.

I'll try flushing after 10K docs next I guess.

> Wow. Thats TOO much. [stops to jump up and down crazily] Wow.

I think there's still lots of scope for improvement.  I've only tried
a performance tuning a few things so far.

> Does "dangerous" mean it could corrupt the btree if interrupted?

Yes - if the power fails or the program is shut down uncleanly, the
database might be corrupt (normally a Xapian database should survive
either event).  But that doesn't give a huge boost - compare the two
graphs on the old box:

http://www.survex.com/~olly/gmaneindexrate.html

"No positional information and O_STREAMING, reuse btree object, no
fdatasync, "dangerous" patch applied:"

vs:

"No positional information and O_STREAMING, reuse btree object, no
fdatasync:"

The patch changes quartz to rewrite blocks in place rather than copying
them so that the switchover can be atomic.  The main benefit here is
that it's a bit more diskcache friendly.  And if you're rebuilding a
large database from scratch on a box in a datacentre connected to a
UPS, you're probably happy to trade a small risk of corruption for
a reduced build time.

Cheers,
    Olly




More information about the Xapian-devel mailing list