similar to: get_matches_estimated and value range

Hello, As I know, get_matches_estimated() return an estimate for the number of documents with matches the query. But now, I found it get a disparity between the return value and real mathced number. For an example: the real matched number is 58, but the return value is 458; so when the users click the hinder page, get a blank page ... so they often complain to me. I found that the main reason is

Hi, I'm getting quite odd results using get_matches_estimated() that I haven't seen before; we've just added a bunch of new data to the database. Xapian 1.0.7, checkatleast is set to 100. The database will get new stuff added to it automatically around 8.30am BST, so it's possible this might affect the links I provide, I guess. But I'll note what is currently happening as

Greets, Is it possible to obtain the actual match count if you're using set_collapse_key()? ie, the total count *before* the collapsing occurs (without using get_mset()). Alternatively, will MSet::get_matches_estimated() return the true - pre-collapse - count, or will it also be affected by collapsing? Thanks Henry

Found by sparse. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 03d8935..d7ace31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@

This patch enlarges the PCI GART aperture to 512 MB. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophisticated approach may be preferable. In particular, if RAMIN is less than 1MB, a 512MB aperture won't fit. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_sgdma.c

Hi all, I found that the figure returned by MSet::get_matches_estimated() varies depending on how results are to be sorted. For instance, in my index, value 4 contains date and time in the format "yyyymmddhhmmss". For the same query, the number of results will be estimated to 20000+ when results are first sorted by date and time with set_sort_by_value_then_relevance(4) and to only 100

Currently Nouveau is unable to dismiss DMA_VTX_PROTECTION errors, which results in an infinite loop in the interrupt handler. These errors are caused both by bugs in the Gallium driver and by user-specified index buffers with out of bounds indices. By mmio-tracing the nVidia drivers, I found out how this is done. On DMA_VTX_PROTECTION, The nVidia driver reads the register 0x402000, always

We are using the --enable-maintainer-mode and will move to git soon. The diff file is attached. *Siddhant Mutha* Undergraduate Student Department of Computer Science and Engineering IIT Madras Chennai http://www.siddhantmutha.com/ <http:/www.siddhantmutha.com/> On Sun, Apr 13, 2014 at 8:26 PM, James Aylett <james-xapian at tartarus.org>wrote: > On 13 Apr 2014, at 15:48, Pallavi

NV10TCL defines the vertex buffer registers both as arrays and as individual named registers. This causes duplicate register definitions and the individual registers are not used either by the DDX or by the Mesa driver. Francisco Jerez said to remove them all. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- renouveau.xml | 49

Hello, With PHP, I try to get spelling corrections but after 2 days of trying I can make it work !!! Here is my < simple > code : <?php require_once( '../global.info.php' ); require_once( 'xapian.class.php' ); require_once( 'xapianencode.func.php' ); // Open the database for searching. try { $database = new XapianDatabase(

i have 300 millions records and my search file like this , i want the newest 10 results that match my query , so i use boolean search and "enquire.set_docid_order(enquire.DESCENDING)" , but this method seems a little slow . when i remove "enquire.set_docid_order(enquire.DESCENDING)" it run much faster . how can i fetch the newest 10 results as fast as possible? search.py

At least it isn't working the way it used to. Code: $db = Search::Xapian::Database->new( $dx ); my $qp = Search::Xapian::QueryParser->new(); my $dbSize=$db->get_doccount(); # $qp->set_stemmer(new Search::Xapian::Stem("english")); # $qp->set_stemming_strategy(STEM_SOME); # $qp->set_default_op($defaultop); my $par =

Hello, I''m using kernel 3.1.0 and I have both / and /home as btrfs. I used suspend to ram quite often and never had a problem, but yesterday I''ve suspended to get into a plane and when I resumed my /home was all about input/output errors. Reboot did not help either. My root (/) did not suffer any problems. Today I''ve upgraded btrfs-progs to latest GIT and tried scrub

Hi All, I've installed Xapian and the php module. I've set up a script for use with scriptindex and dbi2omega for getting data from the db into the index easily, the script file is as follows: =============================== id : field=id title : index title: field=title description : index description : truncate=50 field=content ============================= However, when querying

ttm_bo_delayed_delete has a race condition, because after we do: kref_put(&nentry->list_kref, ttm_bo_release_list); we are not holding the list lock and not holding any reference to objects, and thus every bo in the list can be removed and freed at this point. However, we then use the next pointer we stored, which is not guaranteed to be valid. This was apparently the cause of some

I am suffering for slow searching performance on Xapian. I am using Xapian for indexing about 150,000,000 documents. It was implemented in C++; The performance of searching was not that fast. e.g. Searching a query, which includes about 20 terms, needs 2 secs avg. For searching, I followed such steps: 1. construct a QueryParser for certain string 2. parse the query to get a Xapian::Query

Hello, include <iostream>#include <string>#include <xapian.h>struct document{ std::string title; std::string content; std::string url;}; void indexData(document d) { try { Xapian::WritableDatabase db("/Users/ramesh/Desktop/xapian", Xapian::DB_CREATE_OR_OPEN); Xapian::TermGenerator indexer; Xapian::Stem

Hello, include <iostream>#include <string>#include <xapian.h>struct document{ std::string title; std::string content; std::string url;}; void indexData(document d) { try { Xapian::WritableDatabase db("/Users/ramesh/Desktop/xapian", Xapian::DB_CREATE_OR_OPEN); Xapian::TermGenerator indexer; Xapian::Stem

mple (see attachment). > > Attachments get stripped out by the mailing list, so I?ve made a private gist of the two files here: <https://gist.github.com/jaylett/ce8455b37e2b84422346>. > > Actually, when I run it I get 0 matches, which would explain why you?re just getting the start of the document. However if I adjust things (match the stemming strategy for TermGenerator to

On a multicore Linux platform I'm running a simple c test program, to evaluate xapian performance, and inspect advantages in multiple indexing. I'm starting two threads, and each thread writes to his database. main th -> indexing thread_1 -> db1 (dispatcher) -> indexing thread_2 -> db2 I use sched_setaffinity to bind each indexing thread to a specific core.