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
Re: Composite keys |
Список | 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 по дате отправления: