similar to: 1.2.2/3 performance issue

Hi, I am new to xapian and read somewhere that xapain was using flint before released version 1.1 now it is using chert. I am looking for differences between both flint vs chert respective to xapian and advantages of chert. thanks Smriti

Hello, I am currently using xapian 1.2.23 with the Search::Xapian perl bindings. I'd like to upgrade to 1.4.0, but it seems that there is no suitable Search::Xapian available, and the SWIG-generated bindings are marked as experimental. So, my question is: Do I have to wait for the new API to get stable, or is there another way for me to upgrade to the 1.4.x branch? I'd like to avoid to

As Chert backend is not the default Xapian backend for the 1.2 branch, I am thinking about switching from Flint to Chert. However, I am wondering how do both compare in performance and index size? My indexes are updated quite frequently, so this is my priority. Which is better in this case? Regards, PK

Report by Eric Lindblad 14-09-2015 http://www.ericlindblad.blogspot.com cf: http://permalink.gmane.org/gmane.comp.search.xapian.general/9880 The 'gmake check' compile error on xapian-core-1.2.21/tests/api_backend.cc was resolved by the modification (at the suggestion of a mailing-list member) of the offending string from "q.OP_PHRASE" to "Xapian::Query::OP_PHRASE".

Hi, What's the main difference between chert and flint? What above vs lucene? I am mainly asking about data structure (lexicon, posting list, document data), what's in memory, what's on disk, hash vs b-tree and reasons behind them. Any pointer is appreciated. Thanks! Crystal -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I've a program which: 1. Sets XAPIAN_FLUSH_THRESHOLD=1000 2. Opens a (new) database for write 3. Indexes a few thousand documents 4. Periodically also does queries on the database With 1.1.4, with certain document sets (basically a particular mail folder of mine), Enquire.get_mset() sometimes (but not always) triggers a "RangeError: Value in posting list too

Report by Eric Lindblad 06-10-2015 http://www.ericlindblad.blogspot.com cf: http://permalink.gmane.org/gmane.comp.search.xapian.general/9885 modifications allowing for brass and chert to compile on SFU Interix 3.5 (modified) [code change not performance critical] /xapian-core-1.2.21/backends/brass/brass_check.cc /xapian-core-1.2.21/backends/chert/chert_check.cc #include <climits> +

Hello, The pod-documentation of Database.pm says: > reopen > > This re-opens the database(s) to the latest available version(s). It can be > used either to make sure the latest results are returned, or to recover from > a Xapian::DatabaseModifiedError. I really would like to do that, but as soon as this exception occures my applications dies with a SIGABRT. Is there

Hi guys, I discovered xapian today and I'm trying it because it looks promising compared to other FTS engines. However I'm in a windows environment so it's a bit painful to set up as there is no official binaries. I've heard about http://www.flax.co.uk/xapian_binaries And I'm trying to build their latest release (1.2.8). After a few tries I manage to compile everything with

Report by Eric Lindblad 13-09-2015 http://www.ericlindblad.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9862 I ported xapian-core-1.2.21 to Interix today having disabled the default chert and development brass backends, using flint, which was the 1.0.x series' default, which ships with the 1.2.x series; the disabling do to an unresolved 'ambiguous

Greetings, I've been wondering about the index format and backwards compatibility. We're using the dev version (for chert) and each svn up means that any indexes created prior to this revision cannot be read. Is this purely a cautious move to prevent errors, and, barring any obvious index format changes, can I safely force the current revision to read existing indexes? eg, by

I've just noticed that new indexes no longer have position.{DB,baseA,baseB} files, all previous indexes (I roll indexes every week using xapian-compact) have the position files. The index seems to work but it is returning some odd results, for example if I run a query with the phrase "machine learning" it mostly returns documents containing "machine learning" but it also

Started a new thread - don't want to hijack the previous one (or carry on hijacking it). On Thu, June 10, 2010 05:17, Olly Betts wrote: >> My issue is that exceptions (ie, "Exception: Key too long: length >> was...") > > You are hitting the Btree key size limit. For flint and chert, this > translates to a term length limit of 245 bytes. > If you are using

I've posted the results of 'make check' for xapian "oldstable" (xapian-core-1.2.24) compiled on Slackware-14.0 (32 bit) here: http://nurmi-labs.blogspot.com/p/xapian-linux-old-stable-sse.html xapian-linux-old-stable-sse Summary ./apitest backend none: All 58 tests passed. ./apitest backend inmemory: All 228 tests passed, 8 skipped. ./apitest backend brass: All 304 tests

Report by Eric Lindblad 10-09-2015 http://www.ericlindblad.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9862 interix Yesterday I compiled cppunit-1.12.1 on the Interix g++ (3.3) compiler. xapian Subsequent to disabling the remote backend which caused gmake to skip over the /net/tcpclient.cc:77 error, resulting in xapian libs' compile, today I disabled the

Hello :-) There was probably no good reason to do this build but the Debian 6.0 Squeeze repo version was 1.2.3, we needed 1.2.4 and I didn't think of using the package from unstable. Arch: x86_64 Platform: Linux 2.6 Debian 6.0 (Squeeze) Compiler: gcc version 4.4.5 (Debian 4.4.5-8) Version: 1.2.4 Status: no known problems Source: http://oligarchy.co.uk/xapian/1.2.4/xapian-core-1.2.4.tar.gz

I hadn't noticed any interactive slowdown, but when I got around to running the notmuch performance suite, there seems to be some noticable slowdown with the glass backend (default in Xapian 1.3.5) compared to chert (using xapian 1.2.22) These tests are on an older i7 with 12G of RAM and an SSD. I'm reasonable confident they are CPU bound. One curious thing is the increase in system time

On Thu, Apr 07, 2016 at 08:56:46AM -0300, David Bremner wrote: > I hadn't noticed any interactive slowdown, but when I got around to > running the notmuch performance suite, there seems to be some noticable > slowdown with the glass backend (default in Xapian 1.3.5) compared to > chert (using xapian 1.2.22) Some of this is pretty much expected, though other parts I don't

Dear All, I've tried to build xapian-core 1.4.3 on MSYS2. It fails with attached error (undefined reference to `exp10'). I think it might be missing an explicit link to 'm'. I'm not able to fix this myself as I do not know autotools sufficiently well, but I hope you might be able to help. Cheers, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel.

Le mar 18/05/10 12:10, emmanuel at engelhart.org a ?crit: > Le mar 18/05/10 11:49, "Charlie Hull" charlie at j > uggler.net a ?crit:> On 14/05/2010 18:29, Emmanuel Engelhart > wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Le 14/05/2010 13:31, Charlie Hull a > ?crit> : > >> On 29/04/2010 08:22, Olly