Re: Drawbacks of using BYTEA for PK? - Mailing list pgsql-general

From Alex Satrapa
Subject Re: Drawbacks of using BYTEA for PK?
Date
Msg-id 4004706E.4020405@lintelsys.com.au
Whole thread Raw
In response to Re: Drawbacks of using BYTEA for PK?  (David Garamond <lists@zara.6.isreserved.com>)
Responses Re: Drawbacks of using BYTEA for PK?
Re: Drawbacks of using BYTEA for PK?
Re: Drawbacks of using BYTEA for PK?
List pgsql-general
David Garamond wrote:
> Remember that /sbin/ifconfig output usually include MAC address too. Not
> that MAC addresses are 100% unique, but that should increase the
> uniqueness.

How do you increase uniqueness?  Either a value is unique or it isn't -
if you've got multiple hosts on the network with the same network
address, you're in big trouble!

32 bits for an IP address is a huge number space... but why you'd really
need that much space as a base for your GUID is beyond me. The "host"
part of the address (eg: the last 8 bits in a /24 network block) would
be enough to uniquely identify the 254 hosts on your network. Then add a
32 bit timestamp, and you have 24 bits left for uniquely identifying
things that are created within the same second on the same server -
that's 16M things per second. Busy little shop you'd be running to
exhaust that unique space ;)

Adding extra number space doesn't increase the uniqueness of any
particular key - you have to know how little you can get away with to be
unique. Like distinguishing two humans from each other - you don't need
to unravel the DNA to 3,000 base pairs (3k bits!) if you can settle for
"blonde" versus "auburn" (1 bit!).

I can't remember who said it, but there's a nice quote that's relevant
in this situation: "The true mark of a well designed system is not that
there's nothing left to add, it's that there's nothing left to take away!"

Regards
Alex Satrapa


pgsql-general by date:

Previous
From: Phil Campaigne
Date:
Subject: Incremental Development
Next
From: Enrico Weigelt
Date:
Subject: Re: serverless postgresql