From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Composite keys |
Date: | 2011-10-12 10:26:33 |
Message-ID: | 4E956B59.8030608@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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 indexes that start with the same column,
PostgreSQL is biased toward picking the smallest of them. The amount of
extra I/O needed to navigate a wider index is such that the second
column has to be very selective, too, before it will be used instead of
a narrower single column one. There are plenty of times that the reason
behind "why isn't it using my index?" is "the index is too fat to
navigate efficiently", because the actual number of blocks involved is
factored into the cost computations.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | James Cranch | 2011-10-12 11:40:48 | Re: Rapidly finding maximal rows |
Previous Message | Svetlin Manavski | 2011-10-12 08:55:46 | Join over two tables of 50K records takes 2 hours |