From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: bigint out of range |
Date: | 2019-05-19 00:16:19 |
Message-ID: | 0bea576e-43df-9176-a5da-1aea2bb1b337@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 5/18/19 5:39 PM, Peter J. Holzer wrote:
> On 2019-05-18 17:14:59 -0500, Ron wrote:
>> On 5/18/19 3:49 PM, Peter J. Holzer wrote:
>>
>> On 2019-05-18 15:19:22 -0500, Ron wrote:
>>
>> On 5/18/19 2:27 PM, Peter J. Holzer wrote:
>>
>> On 2019-05-18 10:49:53 -0700, David G. Johnston wrote:
>>
>> You don’t perform math on a hash
>>
>> That's not generally true. Hashes are used for further computation for
>> example in hash tables or in cryptography.
>>
>> How is it "using math" to use a hash key in a hash lookup table?
>>
>> hash modulo table size.
>>
>>
>> I've seen that used when the tablespace is pre-allocated, and you hash modulo
>> the tablespace page number. (Yes, performance tanks when you start filling up
>> pages.) How do you hash on the (ever growing) table size?
> The hash function returns a number in a range much larger than the
> possible number of buckets. 64 bits is a good choice today.
>
> To determine the bucket you need to reduce this number to something in
> the range [0, nr_buckets). This is where modulo comes in:
>
> i = h % nr_buckets
>
> If the the table fills up, you increase nr_buckets, reallocate and
> rehash all entries.
Ouch. Response time on a big table would take a serious hit if that rehash
happened in the middle of the day on a big OLTP system. Even worse if it
were a 24x365 system, because you couldn't schedule an enlargement/rehash
during a down period.
--
Angular momentum makes the world go 'round.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-05-19 02:48:17 | Re: Strange performance degregation in sql function (PG11.1) |
Previous Message | Peter J. Holzer | 2019-05-18 22:39:52 | Re: bigint out of range |