Re: [POC] A better way to expand hash indexes.

On Wed, Mar 29, 2017 at 10:12 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:

>> I wonder if we should consider increasing
>> SPLITPOINT_GROUPS_WITH_ONLY_ONE_PHASE somewhat.  For example, split
>> point 4 is responsible for allocating only 16 new buckets = 128kB;
>> doing those in four groups of two (16kB) seems fairly pointless.
>> Suppose we start applying this technique beginning around splitpoint 9
>> or 10.  Breaking 1024 new buckets * 8kB = 8MB of index growth into 4
>> phases might save enough to be worthwhile.
>>
>
> 10 sounds better point to start allocating in phases.

+1. At splitpoint group 10 we will allocate (2 ^ 9) buckets = 4MB in
total and each phase will allocate 2 ^ 7 buckets = 128 * 8kB = 1MB.

> Few other comments:
> +/*
> + * This is just a trick to save a division operation. If you look into the
> + * bitmap of 0-based bucket_num 2nd and 3rd most significant bit will indicate
> + * which phase of allocation the bucket_num belongs to with in the group. This
> + * is because at every splitpoint group we allocate (2 ^ x) buckets and we have
> + * divided the allocation process into 4 equal phases. This macro returns value
> + * from 0 to 3.
> + */
>
> +#define SPLITPOINT_PHASES_WITHIN_GROUP(sp_g, bucket_num) \
> + (((bucket_num) >> (sp_g - SPLITPOINT_GROUPS_WITH_ONLY_ONE_PHASE)) & \
> + SPLITPOINT_PHASE_MASK)
> This won't work if we change SPLITPOINT_GROUPS_WITH_ONLY_ONE_PHASE to
> number other than 3.  I think you should change it so that it can work
> with any value of  SPLITPOINT_GROUPS_WITH_ONLY_ONE_PHASE.

Fixed, using SPLITPOINT_GROUPS_WITH_ONLY_ONE_PHASE was accidental. All
I need is most significant 3 bits hence should be subtracted by 3
always.

> I think you should name this define as SPLITPOINT_PHASE_WITHIN_GROUP
> as this refers to only one particular phase within group.

Fixed.

Mithun C Y
EnterpriseDB: http://www.enterprisedb.com