From: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | John R Pierce <pierce(at)hogranch(dot)com>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Avoiding surrogate keys |
Date: | 2010-05-04 14:19:41 |
Message-ID: | v2r2f4958ff1005040719z3825ab26g1c2fdd3ccf86970b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, May 4, 2010 at 3:16 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, May 4, 2010 at 9:40 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> On Sat, May 1, 2010 at 4:14 PM, John R Pierce <pierce(at)hogranch(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-05-04 14:31:20 | Re: GeSHi module for Postgresql? |
Previous Message | Justin Pasher | 2010-05-04 14:17:27 | Re: Latest source RPMs for 8.1.20 |