Re: tsearch2 on-demand dictionary loading & using functions in tsearch2

Поиск
Список
Период
Сортировка
От iSteve
Тема Re: tsearch2 on-demand dictionary loading & using functions in tsearch2
Дата
Msg-id 4833CBC2.6020308@bofh.cz
обсуждение исходный текст
Ответ на Re: tsearch2 on-demand dictionary loading & using functions in tsearch2  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: tsearch2 on-demand dictionary loading & using functions in tsearch2
Список pgsql-general
Craig Ringer wrote:
> This is probably a stupid question, but: with PostgreSQL's use of
> shared memory, is it possible to load dictionaries into a small
> reserved shm area when the first backend starts, then use the
> preloaded copy in subsequent backends?
>
> That way the postmaster doesn't have to do any risky work.
>
> Anything that reduces backend startup costs and per-backend unshared
> memory would have to be a good thing.
>
> I've found it useful in the past to share resources with an mmap()ped
> file, too, especially if I want write protection from some or all
> processes. If the postmaster forked a process to generate the
> mmap()able compiled dictionary files on startup then it'd be pretty
> safe from any misbehaviour of the dictionary compiling process.
>
> Then again, I can't say I've personally noticed the cost of loading
> tsearch2 dictionaries.

So the dictionary will be parsed on the first usage by the given
backend, and from that moment on, all running backends and all backends
that will be spawned afterwards will have access to the parsed
dictionary structures thanks to the shm?

That seems to solve all issues - speed, memory and updating. Would this
be a way to go? Obviously, it might boil down to "write a patch", but if
someone actually wrote a patch, would this approach be acceptable?

Thanks,
Steve

PS: Please, CC me, as I am off the list.


В списке pgsql-general по дате отправления:

Предыдущее
От: finecur
Дата:
Сообщение: quote in string
Следующее
От: Gordon
Дата:
Сообщение: Results of stored procedures in WHERE clause