Claudio Freire writes:
> On Mon, Oct 31, 2011 at 2:08 PM, Robert Haas wrote:
>>> Multicolumn indices on (c1, c2, ..., cn) can only be used on where
>>> clauses involving c1..ck with k> I don't think that's true. I believe it can be used for a query that
>> only touches, say, c2. It's just extre
On Mon, Oct 31, 2011 at 2:34 PM, Claudio Freire wrote:
> On Mon, Oct 31, 2011 at 3:24 PM, Robert Haas wrote:
>> Sure it does:
>>
>> rhaas=# create table baz (a bool, b int, c text, primary key (a, b));
>> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
>> "baz_pkey" for table "baz"
On Mon, Oct 31, 2011 at 3:24 PM, Robert Haas wrote:
> Sure it does:
>
> rhaas=# create table baz (a bool, b int, c text, primary key (a, b));
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "baz_pkey" for table "baz"
> CREATE TABLE
> rhaas=# insert into baz select true, g,
> ran
On Mon, Oct 31, 2011 at 1:52 PM, Claudio Freire wrote:
> On Mon, Oct 31, 2011 at 2:08 PM, Robert Haas wrote:
>>> Multicolumn indices on (c1, c2, ..., cn) can only be used on where
>>> clauses involving c1..ck with k>
>> I don't think that's true. I believe it can be used for a query that
>> only
On Mon, Oct 31, 2011 at 2:08 PM, Robert Haas wrote:
>> Multicolumn indices on (c1, c2, ..., cn) can only be used on where
>> clauses involving c1..ck with k
> I don't think that's true. I believe it can be used for a query that
> only touches, say, c2. It's just extremely inefficient.
Does post
On Tue, Oct 11, 2011 at 8:52 PM, Claudio Freire wrote:
> On Tue, Oct 11, 2011 at 5:16 PM, Carlo Stonebanks
> 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
On 10/12/2011 12:39 AM, Carlo Stonebanks wrote:
So with PG I will stick to the general SQL rule that IF I use compound
keys then we have the most selective columns to the left... correct?
There was a subtle point Dave made you should pay close attention to
though. If there are multiple in
the left. correct?
_
From: Dave Crooke [mailto:dcro...@gmail.com]
Sent: October 11, 2011 9:28 PM
To: Claudio Freire
Cc: Carlo Stonebanks; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Composite keys
Claudio is on point, I'll be even more pointed
If pkey
Claudio is on point, I'll be even more pointed
If pkey_id truly is a primary key in the database sense of the term, and
thus unique, then IIUC there is no circumstance in which your composite
index would ever even get used ... all it's doing is slowing down writes :-)
If the query is sufficie
On Tue, Oct 11, 2011 at 5:16 PM, Carlo Stonebanks
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 or
Excuse the noob question, I couldn't find any reading material on this
topic.
Let's say my_table has two fields, pkey_id and another_id. The primary key
is pkey_id and of course indexed.
Then someone adds a composite index on btree(pkey_id, another_id).
Question 1) Is there any benefit
11 matches
Mail list logo
