Re: indexes

From: Ben <bench(at)silentmedia(dot)com>
To: Tom Allison <tom(at)tacocat(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: indexes
Date: 2006-11-24 18:38:00
Message-ID: 67CB5A67-F61D-4C5D-B6B5-63330D89A940@silentmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

It depends how it's going to be used. If you are going to reference
this table in other tables a lot and/or rarely care about what the
name actually is, then the two-column approach is going to be more
efficient. Numbers are smaller and easier to compare than strings.

On Nov 24, 2006, at 6:54 AM, Tom Allison wrote:

> I notice a lot of places where people use the approach of creating
> an index and a unique key like:
>
> CREATE TABLE foo (
> idx SERIAL PRIMARY KEY,
> name varchar(32) UNIQUE NOT NULL
> )
>
> instead of
> CREATE TABLE foo (
> name varchar(32) PRIMARY KEY
> )
>
> If the name is NEVER going to change, is there any advantage to
> doing this?
> If there are many-to-many reference tables (like name-to-friends)
> is this any different?
>
> I've seen this a lot, but I've always assumed that with the
> condition that 'name' would NEVER change, there was no advantage.
>
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

In response to

  • indexes at 2006-11-24 14:54:27 from Tom Allison

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jim Nasby 2006-11-24 19:03:16 Re: pg_dump : option --exclude-schema not recognized
Previous Message Richard Broersma Jr 2006-11-24 18:10:15 Re: IN clause