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

From Robert Haas
Subject Re: can we publish a aset interface?
Date
Msg-id AANLkTikD_Dnu1VmCia9m0Dy5R0jB_83eHkrzY+BnOpyu@mail.gmail.com
Whole thread Raw
In response to Re: can we publish a aset interface?  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: can we publish a aset interface?
Re: can we publish a aset interface?
Re: can we publish a aset interface?
List pgsql-hackers
On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2010/9/7 Robert Haas <robertmhaas@gmail.com>:
>> On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>> I would to use a special memory context for shared data (based on
>>> mmap) and I like impementation of aset. There is only one difference -
>>> aset is based on malloc and I would to use a mmap.
>>>
>>> malloc() is used in AllocSetContextCreate and AllocSetAlloc. These
>>> procedures should be overwritten, but other code and data structures
>>> can be used. This step can be useful for previous discuss about some
>>> more comfortable maintaining of shared memory.
>>>
>>> What do you think about?
>>
>> What would this be good for?
>>
>
> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Fix for pg_upgrade's forcing pg_controldata into English
Next
From: Robert Haas
Date:
Subject: Re: Synchronization levels in SR