On Wed, Mar 29, 2017 at 10:12 AM, Amit Kapila <amit.kapil...@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
yet_another_expand_hashbucket_efficiently_10.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
