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: [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to