On Tue, Mar 28, 2017 at 5:00 AM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:
>> This will go wrong for split point group zero. In general, I feel if
>> you handle computation for split groups lesser than
>> SPLITPOINT_GROUPS_WITH_ONLY_ONE_PHASE in the caller, then all your
>> macros will become much simpler and less error prone.
>
> Fixed, apart from SPLITPOINT_PHASE_TO_SPLITPOINT_GRP rest all macros
> only handle multi phase group. The SPLITPOINT_PHASE_TO_SPLITPOINT_GRP
> is used in one more place at expand index so thought kepeping it as it
> is is better.
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.
Of course, even if we decide to apply this even for very small
splitpoints, it probably doesn't cost us anything other than some
space in the metapage. But maybe saving space in the metapage isn't
such a bad idea anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
