Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux