Re: [HACKERS] POC: Sharing record typmods between backends - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [HACKERS] POC: Sharing record typmods between backends
Date
Msg-id CAFiTN-vmRpxzQdHDeW1iMQZjTYtd3aHkRxOxJ_xbZe-FS5Hu_A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] POC: Sharing record typmods between backends  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] POC: Sharing record typmods between backends  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, May 31, 2017 at 10:57 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Simplehash provides an option to provide your own allocator function
>> to it. So in the allocator function, you can allocate memory from DSA.
>> After it reaches some threshold it expands the size (double) and it
>> will again call the allocator function to allocate the bigger memory.
>> You can refer pagetable_allocate in tidbitmap.c.
>
> That only allows the pagetable to be shared, not the hash table itself.

I agree with you. But, if I understand the use case correctly we need
to store the TupleDesc for the RECORD in shared hash so that it can be
shared across multiple processes.  I think this can be achieved with
the simplehash as well.

For getting this done, we need some fixed shared memory for holding
static members of SH_TYPE and the process which creates the simplehash
will be responsible for copying these static members to the shared
location so that other processes can access the SH_TYPE.  And, the
dynamic part (the actual hash entries) can be allocated using DSA by
registering SH_ALLOCATE function.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: [HACKERS] [PATCH] relocation truncated to fit: citus buildfailure on s390x
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Segmentation fault when creating a BRIN, 10beta1