Re: [POC] A better way to expand hash indexes.
Mithun Cy <mithun.cy@enterprisedb.com>
From: Mithun Cy <mithun.cy@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Amit Kapila <amit.kapila16@gmail.com>, David Steele <david@pgmasters.net>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-04-01T07:01:52Z
Lists: pgsql-hackers
Attachments
- yet_another_expand_hashbucket_efficiently_15.patch (application/octet-stream) patch
On Sat, Apr 1, 2017 at 7:05 AM, Robert Haas <robertmhaas@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
Commits
-
Fix formula in _hash_spareindex.
- b38006ef6d1b 10.0 landed
-
Expand hash indexes more gradually.
- ea69a0dead51 10.0 landed
-
Change hash indexes to store only the hash code rather than the whole indexed
- 4adc2f72a4cc 8.4.0 cited