From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | Bas Scheffers <bas(at)scheffers(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: TSearch and rankings |
Date: | 2004-02-09 16:11:38 |
Message-ID: | 4027B13A.9000204@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Oleg Bartunov wrote:
> On Mon, 9 Feb 2004, Bas Scheffers wrote:
>
>
>>Teodor Sigaev said:
>>
>>>(foo&bar)|(foo&bar&doh)
>>>I think, it's what you want.
>>
>>That simple huh? Can become a bit complicated, doing an OR for all the
>>different combinations, but a quick test I just did did show a higher
>>ranking for the documents that matched the larger query. And quite usable
>>in my application.
>>
>>Do big queries have a significant inpact on search performance? (this is
>>something that is important!)
>
>
> Sure :( In degenerated case you end with query like (word1|word2|word3|..|wordN)
> and it's equivalent running N searches with single word query, which isn't
> effective. Intrinsically, tsearch2 is much faster for long AND queries,
> which is opposite to standard search engines based on inverted indexes.
Ugh. The performance for complex query such as
(foo&bar)|(foo&bar&doh)|(foo&bar&doh&other)
will be equals to simple query foo&bar, because other variants is a stronger
that simplest variant. Performance is defined by number of page readed (we
suppose that CPU is much faster than disks) and if more ANDed words in query
than smaller number of readed pages.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-09 16:16:40 | Re: functions and temporary tables |
Previous Message | Oleg Bartunov | 2004-02-09 15:57:53 | Re: TSearch and rankings |