Skip site navigation (1) Skip section navigation (2)

Re: enums

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 (view raw, whole thread or download thread mbox)
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.


In response to

  • Re: enums at 2005-10-28 20:21:59 from Jim C. Nasby


  • Re: enums at 2005-10-28 21:28:37 from Jim C. Nasby

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2005-10-28 20:47:09
Subject: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
Previous:From: Andrew DunstanDate: 2005-10-28 20:31:36
Subject: Re: enums

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group