Alex,
Yes, linked-lists attached to a hash bucket.
http://en.wikipedia.org/wiki/Hash_table#Collision_resolution
On Mon, Oct 20, 2014 at 2:37 PM, Alex Balashov
wrote:
> Vik,
>
> What exactly do you mean by "separate chains"? I had assumes you were
> referring to lists attached to hash buckets.
>
Vik,
What exactly do you mean by "separate chains"? I had assumes you were
referring to lists attached to hash buckets.
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
correction:
"If this is built in, the user does not have to deal with collisions (or
even know what they are)...it provides scalability without the user having
to do anything."
On Mon, Oct 20, 2014 at 12:55 PM, Vik Killa wrote:
> Alex,
> Separate chains (IMO) is the best way to deal with collis
Alex,
Separate chains (IMO) is the best way to deal with collisions. If this is
built in, the does not have to deal with collisions (or even know what they
are)...it provides scalability without the user having to do anything.
/V
On Mon, Oct 20, 2014 at 12:44 PM, Alex Balashov
wrote:
> Fixes the
Fixes the problem, as opposed to what? What about the htable implementation
does not satisfy you now?
There are only a few ways of dealing with collisions: put them in a flat list
attached to the bucket, devise some algorithm for moving the data to
neighbouring buckets, etc. The list approach
Alex,
It is a collision resolution, yes collisions will still happen but it
essentially fixes the problem.
/V
On Mon, Oct 20, 2014 at 12:13 PM, Alex Balashov
wrote:
> On 10/20/2014 11:17 AM, Vik Killa wrote:
>
> Why isn't htable designed to use separate chains to avoid collisions
>> altogether?
On 10/20/2014 11:17 AM, Vik Killa wrote:
Why isn't htable designed to use separate chains to avoid collisions
altogether?
Chains do not avoid collisions; they're attached to buckets, and simply
represent a particular data structure for handling allocations into the
same bucket.
--
Alex Bal
Why isn't htable designed to use separate chains to avoid collisions
altogether?
On Mon, Aug 19, 2013 at 11:18 AM, Olle E. Johansson wrote:
>
> 19 aug 2013 kl. 17:02 skrev Elena-Ramona Modroiu :
>
> On 8/19/13 4:05 PM, Alex Balashov wrote:
>
> According the docs, the hash table is restricted to
19 aug 2013 kl. 17:02 skrev Elena-Ramona Modroiu :
> On 8/19/13 4:05 PM, Alex Balashov wrote:
>> According the docs, the hash table is restricted to a maximum size of 2^16
>> (65536) buckets.
> it was restricted to 2^14, I just lifted it to positive integer range 2^31
> because it is easier to
19 aug 2013 kl. 17:02 skrev Elena-Ramona Modroiu :
> Hi,
>
> On 8/19/13 4:05 PM, Alex Balashov wrote:
>> According the docs, the hash table is restricted to a maximum size of 2^16
>> (65536) buckets.
> it was restricted to 2^14, I just lifted it to positive integer range 2^31
> because it is
Hi,
On 8/19/13 4:05 PM, Alex Balashov wrote:
According the docs, the hash table is restricted to a maximum size of
2^16 (65536) buckets.
it was restricted to 2^14, I just lifted it to positive integer range
2^31 because it is easier to get now systems with plenty of memory -- it
will be in nex
According the docs, the hash table is restricted to a maximum size of 2^16
(65536) buckets.
This doesn't mean that the htable can only hold 65k entries, just that it's the
maximum number of unique buckets. Assuming a theoretically ideal distribution
where every value has a unique bucket, after
Anyone here?
Thanks!
Ricardo.-
*De:* Ricardo Martinez [mailto:rmarti...@redvoiss.net]
*Enviado el:* miércoles, 14 de agosto de 2013 18:34
*Para:* sr-users@lists.sip-router.org
*Asunto:* Hash Table capacity
Hello list.
I have a question about the HTABLE module. Suppose that I have a mysq
Hello list.
I have a question about the HTABLE module. Suppose that I have a mysql
database with 2 million of records. Is possible to load this table as a
hash table compatible with Kamailio!?
Hope someone can help me.
Thanks,
Ricardo Martinez.-
14 matches
Mail list logo
