1
95%
develop: 36%

Ran 09 Sep 2015 10:10PM UTC

Files 18

Run time 1s

Badge

Embed ▾

Committed 09 Sep 2015 10:08PM UTC coverage: 95.15%. Remained the same

Job # PGVERSION=9.3

Build Type

push

travis-ci

Committed by

jasonmp85

Commit Message

Fix and improve hash token distribution algorithm

There are 2^32 distinct "hash tokens" in our hash space, but we were
using INT32_MAX (2^32 - 1) in the code instead. Because of this, shard
counts which one might expect to divide evenly into the space (such as
16, 32, or 256) had fewer tokens than they should have. The remainder
of the tokens were stuffed into the last shard, causing uneven load.

Though fixing the INT32_MAX bug solves the above case, it still doesn't
deal with the remainder, which can be as large as `shardCount - 1`. We
could continue stuffing it into the top shard, but I find it nicer to
have all shard sizes be within one token of one another.

We previously divided the shard count into the hash token count to get
a "hash token increment" and added that increment each iteration: this
gives something like shardIndex * (hashCount / shardCount). By changing
the grouping to (shardIndex * hashCount) / shardCount, the issue with
distributing the remainder goes away entirely and we get "nice" shards.

Run Details

2158 of 2268 relevant lines covered (95.15%)

315.37 hits per line

Source Files on job 533.1 (PGVERSION=9.3)

Coverage	∆	File	Lines	Relevant	Covered	Missed	Hits/Line

citusdata / pg_shard / 533 / 1
95%
develop: 36%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 533.1 (PGVERSION=9.3)

citusdata / pg_shard / 533 / 1 95% develop: 36%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 533.1 (PGVERSION=9.3)

citusdata / pg_shard / 533 / 1
95%
develop: 36%

README BADGES
x