| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | "D(dot) Dante Lorenso" <dante(at)lorenso(dot)com> |
| Cc: | "Keith C(dot) Perry" <netadmin(at)vcsn(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Drawbacks of using BYTEA for PK? |
| Date: | 2004-01-13 15:51:38 |
| Message-ID: | 20040113155138.GA26266@wolff.to |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Jan 12, 2004 at 20:24:10 -0600,
"D. Dante Lorenso" <dante(at)lorenso(dot)com> wrote:
>
> See what I mean? What do you propose as the best solution for this?
> Not expose
> the sequences to the user and use user-enumerated ids? Then a trigger
> on the
> table would assign ids like:
>
> SELECT (MAX(widget_id)+1) INTO NEW.widget_id
> WHERE cust_id = NEW.cust_id;
>
> But I think after several hundred customer records, this trigger would start
> getting slow. I don't know really, any ideas?
I think it would be better to have a per customer counter. Then the GID
would be customer, customer_sequence. You probably wouldn't want to use
postgres sequences for this. I would expect that generating new ID numbers
isn't so common that updating a counter row in a customer counter table
would be a real problem.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-01-13 15:51:49 | Re: insertion with trigger failed unexpectedly |
| Previous Message | Tom Lane | 2004-01-13 15:50:35 | Re: Nested transaction workaround? |