Re: Composite keys - Mailing list pgsql-performance

From Claudio Freire
Subject Re: Composite keys
Date
Msg-id CAGTBQpYMzj+xufEQBr7_aL3ZjZWaADU1oF40-ji8n8GcpZLj1A@mail.gmail.com
Whole thread Raw
In response to Composite keys  ("Carlo Stonebanks" <stonec.register@sympatico.ca>)
Responses Re: Composite keys
Re: Composite keys
List pgsql-performance
On Tue, Oct 11, 2011 at 5:16 PM, Carlo Stonebanks
<stonec.register@sympatico.ca> wrote:
> Question 2) Regardless of the answer to Question 1 - if another_id is not
> guaranteed to be unique, whereas pkey_id is – there any value to changing
> the order of declaration (more generally, is there a performance impact for
> column ordering in btree composite keys?)

Multicolumn indices on (c1, c2, ..., cn) can only be used on where
clauses involving c1..ck with k<n.

So, an index on (a,b) does *not* help for querying on b.

Furthermore, if a is unique, querying on a or querying on a and b is
equally selective. b there is just consuming space and cpu cycles.

I'd say, although it obviously depends on the queries you issue, you
only need an index on another_id.

pgsql-performance by date:

Previous
From: bricklen
Date:
Subject: Re: Rapidly finding maximal rows
Next
From: Dave Crooke
Date:
Subject: Re: Rapidly finding maximal rows