From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Include Lists for Text Search |
Date: | 2008-03-10 14:59:27 |
Message-ID: | 47D54CCF.1090904@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> Hmm, I can see how some middleware would help with folding or not
> folding the input token, but what about the words coming from the
> dictionary file (particularly the *output* lexeme)? It's not apparent
> to me that it's sensible to try to control that from outside the
> dictionary.
Right now I see an significant advantage of such layer: two possible extension
of dictionary (filtering and storing original form) are independent from nature
of dictionary. So, instead of modifying of every dictionary we can add some
layer, common for all dictionary. With syntax like:
CREATE/ALTER TEXT SEARCH DICTIONARY foo (...) WITH ( filtering=on|off,
store_original=on|off );
Or per token's type/dictionary pair.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-03-10 15:10:55 | Re: [PATCHES] Include Lists for Text Search |
Previous Message | Bruce Momjian | 2008-03-10 14:31:53 | Re: [PATCHES] Include Lists for Text Search |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-03-10 15:02:52 | Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit |
Previous Message | Julius Stroffek | 2008-03-10 14:58:13 | Re: Sun Studio on Linux spinlock patch |