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
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 |