Re: tsearch_core for inclusion - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: tsearch_core for inclusion
Date
Msg-id 45FA5800.7090202@sigaev.ru
Whole thread Raw
In response to Re: tsearch_core for inclusion  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: tsearch_core for inclusion  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: tsearch_core for inclusion  ("Florian G. Pflug" <fgp@phlo.org>)
List 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 by date:

Previous
From: NikhilS
Date:
Subject: Re: UPDATE using sub selects
Next
From: Teodor Sigaev
Date:
Subject: Re: tsearch_core for inclusion