| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
|---|---|
| To: | Rod Taylor <pg(at)rbt(dot)ca> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Fuhr <mike(at)fuhr(dot)org> |
| Subject: | Re: enums |
| Date: | 2005-10-28 20:21:59 |
| Message-ID: | 20051028202159.GT13187@pervasive.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
> The basic idea is that most of us break out schemas by creating fake
> primary keys for the purpose of obtaining performance because using the
> proper primary key (single or multiple columns) is often very slow.
>
> The automatic and transparent creation of a surrogate key by PostgreSQL
> would allow us to dramatically clean up the presentation of our schema
> to the users using the database without the performance hit we currently
> get.
>
>
> It puts surrogate keys (fake primary keys) back to the level of table
> spaces, indexes and other performance enhancements where they belong.
Ahh. Yes, that would definately be great to have. Although it would
probably take me months if not years to get used to not seeing a bunch
of _id fields laying all over the place...
Is SURROGATE part of any of the ANSI specs?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2005-10-28 20:23:26 | Re: enums |
| Previous Message | Jim C. Nasby | 2005-10-28 20:17:58 | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", |