From: Mark Mielke <mark@mark.mielke.cc>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Bill Moran <wmoran@collaborativefusion.com>
Cc: Mario Weilguni <mweilguni@sime.com>
Cc: valiouk@yahoo.co.uk, Jay <arrival123@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Using PK value as a String
Date: Tue, 12 Aug 2008 10:11:50 -0400
Message-ID: <48A19A26.3090703@mark.mielke.cc> (raw)
In-Reply-To: <87hc9qwdke.fsf@oxford.xeocode.com>
References: <18986.60888.qm@web25807.mail.ukl.yahoo.com>
<48A15ECF.5030203@sime.com>
<87od3ywg4n.fsf@oxford.xeocode.com>
<20080812090621.1cafbbab.wmoran@collaborativefusion.com>
<48A18E64.10707@mark.mielke.cc>
<87hc9qwdke.fsf@oxford.xeocode.com>
Gregory Stark wrote:
> "Mark Mielke" <mark@mark.mielke.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@mielke.cc>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark@mark.mielke.cc, stark@enterprisedb.com, wmoran@collaborativefusion.com, mweilguni@sime.com, arrival123@gmail.com
Subject: Re: Using PK value as a String
In-Reply-To: <48A19A26.3090703@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox