| From: | Rod Taylor <pg(at)rbt(dot)ca> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| 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:36:26 |
| Message-ID: | 1130531786.846.139.camel@home |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2005-10-28 at 15:21 -0500, Jim C. Nasby wrote:
> 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?
No, but neither is an index, rollback segment, or table space. The ANSI
spec doesn't usually deal with performance tweaks that are the
responsibility of the DBA.
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2005-10-28 20:47:09 | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", |
| Previous Message | Andrew Dunstan | 2005-10-28 20:31:36 | Re: enums |