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
