[Xapian-discuss] Ranking and term proximity
William Crawford
william at sciencephoto.co.uk
Tue Sep 6 11:31:07 BST 2011
On Tuesday 06 September 2011 07:35:32 goran kent wrote:
> Reminds me of
> http://trac.xapian.org/ticket/326 - chert (without patches, but even
> with, it's still bad) is 7x SLOWER than the older flint format.
> That's embarrassing. Yes, one can argue that chert *may* perform
> better with larger indexes, but hell, that's still a bad start... Can
> you imagine trying to justify/explain that kind of degradation in a
> commercial product? You'd be laughed right out the conference room.
I'd like to pipe up from the back here and make an observation.
I've got an index that's about 700M, on a server with 24G RAM, and I'd much
rather have the faster search that comes from /not/ trying too hard to
compress the data. I understand there are use-cases where everything can't be
cached, but perhaps there's a need for either two backends (mono- and megalith
would be good names?) or a flag to pass to the WritableDatabase when creating?
More information about the Xapian-discuss
mailing list