Re: tsearch_core for inclusion

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: tsearch_core for inclusion
Дата
Msg-id 45FA5800.7090202@sigaev.ru
обсуждение исходный текст
Ответ на Re: tsearch_core for inclusion  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: tsearch_core for inclusion  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: tsearch_core for inclusion  ("Florian G. Pflug" <fgp@phlo.org>)
Список pgsql-hackers
> Yeah, that one.  It might be more consistent to spell it as "fulltext_ops"
> but I wouldn't insist on it.

Hmm, you are prompting an idea to me how to simplify usage of full text index in  simple cases.

CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);

Fulltext_ops opclass parses the document similarly to_tsvector nad stores 
lexemes in gin index. It's a full equalent of
CREATE INDEX ... ( to_tsvector( textcolumn ) )

And, let we define operation text @ text, which is equivalent of text @@ 
plainto_tsquery(text), so, queries will look like
SELECT * FROM tblname WHERE textcolumn @ textquery;

Fulltext_ops can speedup both operation, text @@ tsquery and text @ text. 
Because gin API has extractQuery method which calls once per index scan and it 
can parse query to lexemes.

Some disadvantage: with that way it isn't possible make fast ranking - there is 
no stored parsed text. And, fulltext_ops may be done for GiST index too, but 
fulltext opclass will be lossy which means slow search due to reparse texts for 
each index match.

BTW, simple syntax sugar for CREATE INDEX (fulltext_ops) may be done:
CREATE INDEX idxname ON tblname USING FULLTEXT (textcolumn)

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: NikhilS
Дата:
Сообщение: Re: UPDATE using sub selects
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: tsearch_core for inclusion