Re: tsearch2 on-demand dictionary loading & using functions in tsearch2
От | Teodor Sigaev |
---|---|
Тема | Re: tsearch2 on-demand dictionary loading & using functions in tsearch2 |
Дата | |
Msg-id | 48304745.6090606@sigaev.ru обсуждение исходный текст |
Ответ на | tsearch2 on-demand dictionary loading & using functions in tsearch2 (iSteve <isteve@bofh.cz>) |
Ответы |
Re: tsearch2 on-demand dictionary loading & using functions in tsearch2
|
Список | 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@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-general по дате отправления: