Re: tsearch2 on-demand dictionary loading & using functions in tsearch2 - Mailing list pgsql-general

From Teodor Sigaev
Subject Re: tsearch2 on-demand dictionary loading & using functions in tsearch2
Date
Msg-id 4830121D.9050204@sigaev.ru
Whole thread Raw
In response to tsearch2 on-demand dictionary loading & using functions in tsearch2  (iSteve <isteve@bofh.cz>)
Responses Re: tsearch2 on-demand dictionary loading & using functions in tsearch2  (iSteve <isteve@bofh.cz>)
List pgsql-general
>  * Considering the database is loaded separately for each session, does
> this also imply that each running backend has a separate dictionary
> stored in memory?

Yes.
>
> As for downsides, I only really see two:
>  * Tracking updates of dictionaries - but it's reasonable to believe
> that new connections get open more often than the dictionary gets
> updated. Also, this might be easily solved by stat()-ing the dictionary
> file before starting up session, and only have the server reload it if
> there's a notified change.
>  * Possibly complicated to implement?

Keeping dictionary up to date - it's a most difficult part here. Configuration
of dictionary might be done by ALTER command - so, parent process (and all
currently running backends) should get that information to reload dictionary.


> 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.

Yes, of course, you can develop your dictionary (-ies) and parser. Dut only in
C, because they are critical for performance.
--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

pgsql-general by date:

Previous
From: Vlad Kosilov
Date:
Subject: pg_standby gets stuck on a smaller wal file
Next
From: Ivan Sergio Borgonovo
Date:
Subject: Re: Postgresql MVCC, Read Committed Isolation Level and taking "snapshot"