Re: [HACKERS] Parallel bitmap heap scan - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [HACKERS] Parallel bitmap heap scan
Date
Msg-id CAFiTN-v3eBpob4nGMAxHpis9+wiRsSJb4gD3f6sT1Jt=nqs5Cg@mail.gmail.com
Whole thread Raw
In response to Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [HACKERS] Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Wed, Dec 21, 2016 at 3:23 PM, Andres Freund <andres@anarazel.de> wrote:

Sorry for the delayed response.

> If we go there, it seems better to also wrap the memory context based approach
> in the allocator.

One option is we can keep default allocator in the simple hash, and if
the caller doesn't supply any functions we can use default functions
as I have shown below.

+/* default allocator function */
+static void *
+SH_DEFAULT_ALLOC(Size size, void *args)
+{
+ MemoryContext context = (MemoryContext) args;
+
+ return MemoryContextAllocExtended(context, size,
+  MCXT_ALLOC_HUGE | MCXT_ALLOC_ZERO);
+}
+
+/* default allocator function */
+static void
+SH_DEFAULT_FREE(void *pointer, void *args)
+{
+ pfree(pointer);
+}
+

+SH_CREATE(MemoryContext ctx, uint32 nelements, SH_ALLOCATOR *alloc){
- SH_TYPE    *tb;
- uint64 size;
+ SH_TYPE     *tb;
+ uint64 size;
 tb = MemoryContextAllocZero(ctx, sizeof(SH_TYPE)); tb->ctx = ctx;
@@ -294,9 +336,18 @@ SH_CREATE(MemoryContext ctx, uint32 nelements)
 SH_COMPUTE_PARAMETERS(tb, size);

- tb->data = MemoryContextAllocExtended(tb->ctx,
-  sizeof(SH_ELEMENT_TYPE) * tb->size,
-  MCXT_ALLOC_HUGE | MCXT_ALLOC_ZERO);
+ if (!alloc)
+ {
+ tb->alloc = palloc(sizeof(SH_ALLOCATOR));
+ tb->alloc->HashAlloc = SH_DEFAULT_ALLOC;
+ tb->alloc->HashFree = SH_DEFAULT_FREE;
+ tb->alloc->args = tb->ctx;
+ }
+ else
+ tb->alloc = alloc;
+
+ tb->data = tb->alloc->HashAlloc(sizeof(SH_ELEMENT_TYPE) * tb->size,
+ tb->alloc->args);

Other the another option is, that we can always make caller to provide
an allocator. But this way every new user for simple hash need to take
care of having allocator.

What is your opinion?


>This also needs docs, including a warning that just
> using an allocator in shared memory does *NOT* allow the hash table to be
> used in shared memory in the general case.

Make sense.


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



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] IF (NOT) EXISTS in psql-completion
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: session server side variables