Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 0D32265029E for ; Tue, 12 Aug 2008 11:19:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 73133-03-3 for ; Tue, 12 Aug 2008 11:18:59 -0300 (ADT) X-Greylist: delayed 00:06:39.098894 by SQLgrey-1.7.6 Received: from smtp115.rog.mail.re2.yahoo.com (smtp115.rog.mail.re2.yahoo.com [68.142.225.231]) by postgresql.org (Postfix) with SMTP id CFE6D65026D for ; Tue, 12 Aug 2008 11:18:32 -0300 (ADT) Received: (qmail 13043 invoked from network); 12 Aug 2008 14:11:51 -0000 Received: from unknown (HELO ?99.245.226.206?) (markmielke@rogers.com@99.245.226.206 with plain) by smtp115.rog.mail.re2.yahoo.com with SMTP; 12 Aug 2008 14:11:51 -0000 X-YMail-OSG: 3t5We08VM1nzK5Kaftke0VN7K0Z9wRLU2Z1Th8W8lRHhR.CAg_i2aobNvsfxTRXnAg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A19A26.3090703@mark.mielke.cc> Date: Tue, 12 Aug 2008 10:11:50 -0400 From: Mark Mielke User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Gregory Stark CC: Bill Moran , Mario Weilguni , valiouk@yahoo.co.uk, Jay , pgsql-performance@postgresql.org Subject: Re: Using PK value as a String 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> In-Reply-To: <87hc9qwdke.fsf@oxford.xeocode.com> Content-Type: multipart/alternative; boundary="------------000309080708060109010504" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200808/122 X-Sequence-Number: 31003 This is a multi-part message in MIME format. --------------000309080708060109010504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gregory Stark wrote: > "Mark Mielke" 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 --------------000309080708060109010504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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>
--------------000309080708060109010504--