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

From Andres Freund
Subject Re: [HACKERS] Parallel bitmap heap scan
Date
Msg-id 20161221095321.srmraalhh5qet7x7@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
Hi,

On 2016-12-21 10:36:13 +0530, Dilip Kumar wrote:
> diff --git a/src/include/lib/simplehash.h b/src/include/lib/simplehash.h
> index 12aedbc..b9a05e6 100644
> --- a/src/include/lib/simplehash.h
> +++ b/src/include/lib/simplehash.h
> @@ -66,6 +66,7 @@
>  #define SH_STATUS_EMPTY SH_MAKE_NAME(EMPTY)
>  #define SH_STATUS_IN_USE SH_MAKE_NAME(IN_USE)
>  #define SH_ITERATOR SH_MAKE_NAME(iterator)
> +#define SH_ALLOCATOR SH_MAKE_NAME(alloc)
>  
>  /* function declarations */
>  #define SH_CREATE SH_MAKE_NAME(create)
> @@ -90,6 +91,18 @@
>  /* generate forward declarations necessary to use the hash table */
>  #ifdef SH_DECLARE
>  
> +typedef struct SH_ALLOCATOR
> +{
> +    /* Allocation function */
> +    void     *(*HashAlloc) (Size size, void *args);
> +
> +    /* Free function */
> +    void      (*HashFree) (void *pointer, void *args);
> +
> +    /* Arguments to be passed to alloc and free functions */
> +    void     *args;
> +} SH_ALLOCATOR;
> +
>  /* type definitions */
>  typedef struct SH_TYPE
>  {
> @@ -112,6 +125,9 @@ typedef struct SH_TYPE
>      /* hash buckets */
>      SH_ELEMENT_TYPE *data;
>  
> +    /* hash allocator */
> +    SH_ALLOCATOR    *alloc;
> +
>      /* memory context to use for allocations */
>      MemoryContext ctx;
>  
> @@ -133,7 +149,8 @@ typedef struct SH_ITERATOR
>  } SH_ITERATOR;

>  /* externally visible function prototypes */
> -SH_SCOPE SH_TYPE *SH_CREATE(MemoryContext ctx, uint32 nelements);
> +SH_SCOPE SH_TYPE *SH_CREATE(MemoryContext ctx, uint32 nelements,
> +                            SH_ALLOCATOR *alloc);
>  SH_SCOPE void SH_DESTROY(SH_TYPE *tb);
>  SH_SCOPE void SH_GROW(SH_TYPE *tb, uint32 newsize);
>  SH_SCOPE SH_ELEMENT_TYPE *SH_INSERT(SH_TYPE *tb, SH_KEY_TYPE key, bool *found);
> @@ -281,7 +298,7 @@ SH_ENTRY_HASH(SH_TYPE *tb, SH_ELEMENT_TYPE * entry)
>   * allocating required memory in the passed-in context.
>   */
>  SH_SCOPE SH_TYPE *
> -SH_CREATE(MemoryContext ctx, uint32 nelements)
> +SH_CREATE(MemoryContext ctx, uint32 nelements, SH_ALLOCATOR *alloc)
>  {
>      SH_TYPE    *tb;
>      uint64        size;
> @@ -294,9 +311,19 @@ 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);
> +    tb->alloc = alloc;
> +
> +    /*
> +     * If allocation handle is passed then use allocation function from the
> +     * handle otherwise use standard allocator.
> +     */
> +    if (tb->alloc != NULL)
> +        tb->data = tb->alloc->HashAlloc(sizeof(SH_ELEMENT_TYPE) * tb->size,
> +                                        tb->alloc->args);
> +    else
> +        tb->data = MemoryContextAllocExtended(tb->ctx,
> +                                        sizeof(SH_ELEMENT_TYPE) * tb->size,
> +                                        MCXT_ALLOC_HUGE | MCXT_ALLOC_ZERO);

If we go there, it seems better to also wrap the memory context based approach
in the allocator.  This also needs docs, including a warning that just
using an allocator in shared memory does *NOT* allow the hashtable to be
used in shared memory in the general case.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] simplehash vs. pgindent
Next
From: Fujii Masao
Date:
Subject: Re: [HACKERS] Quorum commit for multiple synchronous replication.