On Tue, Mar 28, 2017 at 5:00 AM, Mithun Cy <mithun...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
