On Tue, Sep 7, 2010 at 11:18 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mar sep 07 10:13:12 -0400 2010:
>
>> > 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.
>
> Hmm, surely you could store offsets instead of absolute pointers.
Surely you could. But then where does palloc come in? As Tom said
upthread, the right thing to do here is to create a pre-compiler that
outputs a pointer-free representation which you can then mmap().
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
