On Tue, May 4, 2010 at 3:16 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Tue, May 4, 2010 at 9:40 AM, Merlin Moncure <mmonc...@gmail.com> wrote: >> On Sat, May 1, 2010 at 4:14 PM, John R Pierce <pie...@hogranch.com> wrote: >>> >>> If your 'natural key' is a large text field, I'd have to assume there's some >>> point at which a surrogate index would be more efficient. Would this be >>> above a few dozen characters, or a few 100 characters? I wouldn't want a >>> PK based on a multi-K byte text field for a table that has many 10s or 100s >>> of 1000s of rows, for sure. > > one more note about this. if you truly have a situation where a multi > kilobyte chunk of data is the key, you can always digest it and use > that. you lose the natural ordering -- but in these type of cases it > usually doesn't matter. >
99% of all cases, where I introduced bigint surrogate key, in tables that hold account, customers, and that sort of bollocks, were straight wins, sometimes measuring 3-4x. Another thing, If your PK changes, it is no longer a PK, you can't rely on it. -- GJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
