Re: Using PK value as a String

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Bill Moran <wmoran(at)collaborativefusion(dot)com>, Mario Weilguni <mweilguni(at)sime(dot)com>, valiouk(at)yahoo(dot)co(dot)uk, Jay <arrival123(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Using PK value as a String
Date: 2008-08-12 14:11:50
Message-ID: 48A19A26.3090703@mark.mielke.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Gregory Stark wrote:
> "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc> writes:
>
>
>> - Increased keyspace. Even if keyspace allocation is performed, an int4 only
>> has 32-bit of keyspace to allocate. The IPv4 address space is already over 85%
>> allocated as an example of how this can happen. 128-bits has a LOT more
>> keyspace than 32-bits or 64-bits.
>>
>
> The rest of your points are valid (though not particularly convincing to me
> for most applications) but this example is bogus. The IPv4 address space is
> congested because of the hierarchic nature of allocations. Not because there
> is an actual shortage of IPv4 addresses themselves. There would be enough IPv4
> for every ethernet device on the planet for decades to come if we could
> allocate them individually -- but we can't.
>

I don't disagree. Obviously, most systems people work with do not
require 2**32 records. You trimmed my bottom statement where "most
systems don't require any of these benefits - it's only a just in case." :-)

The point is valid - 128-bits has more keyspace than 32-bits or 64-bits.
The relevance of this point to a particular application other than
Facebook, Google, or Yahoo, is probably low or non-existent.

Cheers,
mark

> That is, when allocating an organization 100 addresses if they want to be able
> to treat them as a contiguous network they must be allocated 128 addresses.
> And if they might ever grow to 129 they're better off just justifying 256
> addresses today.
>
> That's not an issue for a sequence generated primary key. Arguably it *is* a
> problem for UUID which partitions up that 128-bits much the way the original
> pre-CIDR IPv4 addressing scheme partitioned up the address. But 128-bits is so
> much bigger it avoids running into the issue.
>
> The flip side is that sequence generated keys have to deal with gaps if record
> is deleted later. So the relevant question is not whether you plan to have 2
> billion users at any single point in the future but rather whether you plan to
> ever have had 2 billion users total over your history. I suspect large
> networks like Yahoo or Google might be nearing or past that point now even
> though they probably only have a few hundred million current users.
>
>

--
Mark Mielke <mark(at)mielke(dot)cc>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Moritz Onken 2008-08-12 14:17:58 Re: Using PK value as a String
Previous Message Mathias Stjernström 2008-08-12 13:57:09 Re: Using PK value as a String