Re: can we publish a aset interface?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> I try to solve performance problems with czech tsearch. I checked
>> serialization and deserialization, but this decrease load time only to
>> 100ms (from 500) that is too much for us. After some gaming with mmap
>> I thinking so there some chance to preallocate mmap memory, and then
>> use a special memory context based on mmap instead of malloc.
>> Teoretically I can copy aset interface - this module probably never be
>> in core (this problem is probably local - only Czech), but it isn't
>> nice. So I asking.

> I don't see how you could do anything with this that you can't do with
> the existing implementation. It's not as if you can store pointers
> into an mmap'd block and then count on them being valid the next time
> you map the file... it might not end up at the same offset.

More to the point, this entire approach to speeding up dictionary loading
has already been proposed and rejected, and it'll get rejected again if
it's submitted.

The conclusion of the previous discussion was that we should build
"precompiled" dictionaries, using some pointer-free representation,
which would be stored in files that could be either mmap'd in or just
read in if running on a platform lacking mmap. There is no need for
any shmem allocator in that implementation.

regards, tom lane