Re: Composite keys

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: Composite keys
Дата
Msg-id CAGTBQpYMzj+xufEQBr7_aL3ZjZWaADU1oF40-ji8n8GcpZLj1A@mail.gmail.com
обсуждение исходный текст
Ответ на Composite keys  ("Carlo Stonebanks" <stonec.register@sympatico.ca>)
Ответы Re: Composite keys  (Dave Crooke <dcrooke@gmail.com>)
Re: Composite keys  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: bricklen
Дата:
Сообщение: Re: Rapidly finding maximal rows
Следующее
От: Dave Crooke
Дата:
Сообщение: Re: Rapidly finding maximal rows