Re: Parallel bitmap heap scan

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel bitmap heap scan
Date: 2016-12-26 09:44:30
Message-ID: CAFiTN-v3eBpob4nGMAxHpis9+wiRsSJb4gD3f6sT1Jt=nqs5Cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 21, 2016 at 3:23 PM, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-12-26 09:54:59 Re: proposal: session server side variables
Previous Message Kyotaro HORIGUCHI 2016-12-26 08:40:58 Re: IF (NOT) EXISTS in psql-completion