2010/3/18 Pavel Stehule <pavel.steh...@gmail.com>: > 2010/3/18 Tom Lane <t...@sss.pgh.pa.us>: >> Pavel Stehule <pavel.steh...@gmail.com> writes: >>> I know so Tom worries about using of share memory. >> >> You're right, and if I have any say in the matter no patch like this >> will ever go in. >> >> What I would suggest looking into is some way of preprocessing the raw >> text dictionary file into a format that can be slurped into memory >> quickly. The main problem compared to the way things are done now >> is that the current internal format relies heavily on pointers. >> Maybe you could replace those by offsets? > > You have to maintain a new application :( There can be a new kind of bugs. > > I playing with preload solution now. And I found a new issue. > > I don't know why, but when I preload library with large mem like > ispell, then all next operations are ten times slower :( >
this strange issue is from very large memory context. When I don't join tseach cached context with working context, then this issue doesn't exists. Datum dpreloaddict_init(PG_FUNCTION_ARGS) { <------>if (prepd == NULL) <------><------>return dispell_init(fcinfo); // use without preloading <------>else <------>{ <------> <------><------>//return PointerGetDatum(prepd); <------><------>/*. <------><------> * Add preload context to current conntext -- when this code is active, then I have a issue <------><------> */ <------><------>preload_ctx->parent = CurrentMemoryContext; <------><------>preload_ctx->nextchild = CurrentMemoryContext->firstchild; <------><------>CurrentMemoryContext->firstchild = preload_ctx; <------><------> <------><------>return PointerGetDatum(prepd); <------>} } Pavel > > When I reduce memory with simple allocator, then this issue is > removed, but it is strange. > > Pavel > > >> >> regards, tom lane >> > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers