Skip site navigation (1) Skip section navigation (2)

Re: Composite keys

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Composite keys
Date: 2011-10-31 18:42:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Mon, Oct 31, 2011 at 2:34 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Mon, Oct 31, 2011 at 3:24 PM, Robert Haas <robertmhaas(at)gmail(dot)com> 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"
>> rhaas=# insert into baz select true, g,
>> random()::text||random()::text||random()::text||random()::text from
>> generate_series(1,400000) g;
> Ok, that's artificially skewed, since the index has only one value in
> the first column.
> But it does prove PG considers the case, and takes into account the
> number of values it has to iterate over on the first column, which is
> very very interesting and cool.

Yes.  As your experience indicates, it's rare for this to be the best
plan.  But it is considered.  So there you have it.  :-)

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-performance by date

Next:From: Merlin MoncureDate: 2011-10-31 18:50:06
Subject: Re: SSL encryption makes bytea transfer slow
Previous:From: Claudio FreireDate: 2011-10-31 18:34:25
Subject: Re: Composite keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group