Re: Problem with site doc search

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>, "Gevik Babakhani" <pgdev(at)xs4all(dot)nl>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>
Subject: Re: Problem with site doc search
Date: 2008-04-16 09:25:12
Message-ID: 20080416112512.43b32997@mha-laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Cédric Villemain wrote:
> Le Wednesday 16 April 2008, Magnus Hagander a écrit :
> > Cédric Villemain wrote:
> > > Notice that :
> > >
> > > http://search.postgresql.org/search?q=tom+lane&m=1&l=&d=1&s=r
> > > and
> > > http://search.postgresql.org/search?q=tom+lane&m=1&l=&d=1&s=d
> > >
> > > do not provide same result (3 results by date, 1 by rank) even if
> > > only the sorting is changed.
> >
> > Actually, I get 5 and 7, in the other order.
> >
> > The reason for this is that Tom Lane is way too active. It's
> > gin_fuzzy_search_limit that's doing the restriction first, and the
> > date restriction comes in later.
>
> Yes, you are perfectly right. Can I suggest to deactivate
> gin_fuzzy_search_limit (or increase the value) when one condition
> (and use the condition earlier) can considerably reduce the number of
> results (like the 'post date' here) ?

You'd have to convince the planner to actually not use an indexscan at
all on the tsvector. Normally it'll choose an index scan on each and
then a bitmap join, and we don't want to bring back so many rows...

//Magnus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-04-16 09:46:58 Re: Improving planner variable handling
Previous Message Cédric Villemain 2008-04-16 09:15:18 Re: Problem with site doc search