Re: tsearch_core for inclusion

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tsearch_core for inclusion
Date: 2007-03-16 08:40:32
Message-ID: 45FA5800.7090202@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2007-03-16 08:44:58 Re: tsearch_core for inclusion
Previous Message NikhilS 2007-03-16 07:44:25 Re: UPDATE using sub selects