Message-ID: <45A61F18.1030306@archonet.com>
Date: Thu, 11 Jan 2007 11:27:20 +0000
From: Richard Huxton <dev@archonet.com>
User-Agent: IceDove 1.5.0.9 (X11/20061220)
MIME-Version: 1.0
To: arnaulist@andromeiberica.com
Cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Does it matters the column order in indexes and constraints
References: <45A617F2.6040802@andromeiberica.com>
In-Reply-To: <45A617F2.6040802@andromeiberica.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Arnau wrote:
> Hi all,
> 
>   I've got a doubt about how to create an index and a primary key. Lets 
> say I have the following table:

>   The country_id column can have maybe 100 - 250 different values.
>   The customer_id column can have as much several hundred values (less 
> than 1000).
>   The telephone is where all will be different.
> 
>   So my doubt is, in terms of performance makes any difference the order 
> of the primary key fields? The same in the index definition? I have 
> checked the postgresql documentation I haven't been able to find 
> anything about.

Well, it makes no *logical* difference, but clearly the index will have 
a different shape depending on how you create it.

If you regularly write queries that select by country but not by 
customer, then use (country_id,customer_id). A more likely scenario is 
that you will access via customer, which in any case is more selective.

However, since both colums reference other tables you might want to make 
sure the "secondary" column has its own index if you do lots of updating 
on the target FK table.

But, the more indexes you have the slower updates will be on this table, 
since you'll need to keep the indexes up-to-date too.

I find it's easier to spot where to put indexes during testing. It's 
easy to add indexes where they're never used.

HTH
-- 
   Richard Huxton
   Archonet Ltd