From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | iSteve <isteve(at)bofh(dot)cz> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: tsearch2 on-demand dictionary loading & using functions in tsearch2 |
Date: | 2008-05-18 15:12:05 |
Message-ID: | 48304745.6090606@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Hmm, good point; I presume "accept the fact that settings change won't
> propagate to other backends until reconnect" would not be acceptable
> behavior, even if documented along with the relevant configuration option?
I suppose so. That was one of the reasons to move tsearch into core and it will
be too regrettable to lost that feature again.
>>> As for my second question, is it possible to use functions in
>>> tsearch2? For example, writing my own stemmer in PL/pgSQL or in C as
>>> a postgres function.
> I've had something different in mind. Considering there are already
> facilities to use functions, be it PL/pgSQL, PL/Python or C, why not
> just use those with the condition that the function must accept
> some-arguments and return some-result? Or would using this, even while
> using C as the language used for the actual parser, slow things down too?
API to dictionary and parser intentionally utilizes complex (and nested)
C-structures to decrease overheads. During parse of text postgres makes two call
of parser (one call - parser returns word, second - word delimiter. Space is a
lexeme too! Although it's not a subject to index) and one call of dictionary per
word. So, if your language can work with C-structures then you can use that
language with tsearch with more or less performance pay. PL/pgSQL hasn't this
capability.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Shane Ambler | 2008-05-18 15:52:07 | Re: Link tables from different databases |
Previous Message | Craig Ringer | 2008-05-18 14:57:28 | Re: updating a row referenced by a foreign key |