Re: can we publish a aset interface? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: can we publish a aset interface?
Date
Msg-id 10040.1283871395@sss.pgh.pa.us
Whole thread Raw
In response to Re: can we publish a aset interface?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule <pavel.stehule@gmail.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Synchronous replication - patch status inquiry
Next
From: Teodor Sigaev
Date:
Subject: Re: proposal: tsearch dictionary initialization hook