Re: strange query plan with LIMIT

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: tv(at)fuzzy(dot)cz
Cc: anthony(dot)shipman(at)symstream(dot)com, pgsql-performance(at)postgresql(dot)org, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: strange query plan with LIMIT
Date: 2011-06-10 15:22:28
Message-ID: BANLkTi=WOo6GnFE3txMuOg7kDSfRmM4aiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Jun 10, 2011 at 1:22 PM, <tv(at)fuzzy(dot)cz> wrote:
>> If I had set the primary key to (diag_id, create_time) would simple
>> queries on
>> diag_id still work well i.e.
>>     select * from tdiag where diag_id = 1234;
>
> Yes. IIRC the performance penalty for using non-leading column of an index
> is negligible. But why don't you try that on your own - just run an
> explain and you'll get an immediate answer if that works.

The effective penalty, which you don't see on your explain, is the
size of the index.

Depends on the data stored there, but the index can grow up to double
size (usually less than that), and the bigger index is slower for all
operations.

But, in general, if you need both a single-column a multi-column
index, just go for a multipurpose multicolumn one.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2011-06-10 16:49:38 Re: how much postgres can scale up?
Previous Message Pierre C 2011-06-10 13:57:25 Re: how much postgres can scale up?