On Sat, Apr 1, 2017 at 7:05 AM, Robert Haas <robertmh...@gmail.com> wrote: > Hmm, don't the changes to contrib/pageinspect/expected/hash.out > indicate that you've broken something? The hash index has only 4 > buckets, so the new code shouldn't be doing anything differently, but > you've got highmask and lowmask changing for some reason.
The high mask calculation has got changed a bit to accommodate num_buckets which are not 2-power number. If num_bucket is not a 2-power number highmask should be its immediate next ((2^x) - 1) and low mask should be (highmask >> 1) to cover the first half of the buckets. Trying to generalize same has changed the masks for 2-power num_buckets from older implementation. + /* set highmask, which should be sufficient to cover num_buckets. */ + metap->hashm_highmask = (1 << (_hash_log2(num_buckets))) - 1; But this do not cause any adverse effect the high and low mask is sufficiently enough to get the same mod, If we add one more bucket then @_hash_expandtable, immediately we make the masks bigger. if (new_bucket > metap->hashm_highmask) { /* Starting a new doubling */ metap->hashm_lowmask = metap->hashm_highmask; metap->hashm_highmask = new_bucket | metap->hashm_lowmask; The state (metap->hashm_highmask == metap->hashm_maxbucket) is natural state to occur while hash index is growing and just before doubling. Another choice I could have made is bump a number so that for 2-power num_buckets will get highmask as similar to old code, and non 2-power num_buckets highmask will be immediate next ((2^x) - 1). + /* set highmask, which should be sufficient to cover num_buckets. */ + metap->hashm_highmask = (1 << (_hash_log2(num_buckets + 1))) - 1; It was just a personal preference I choose 1, as it appeared consistent with running state of hash index expansion. Also adding a patch which implements the 2nd way. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com
yet_another_expand_hashbucket_efficiently_15.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