Re: Poor index choice -- multiple indexes of the same columns - Mailing list pgsql-performance

From Josh Berkus
Subject Re: Poor index choice -- multiple indexes of the same columns
Date
Msg-id 200506271537.41797.josh@agliodbs.com
Whole thread Raw
In response to Poor index choice -- multiple indexes of the same columns  ("Karl O. Pinc" <kop@meme.com>)
Responses Re: Poor index choice -- multiple indexes of the same
List pgsql-performance
Karl,

> Seems to me that when there's a constant value in the query
> and an = comparision it will always be faster to use the (b-tree)
> index that's ordered first by the constant value, as then all further
> blocks are guarenteed to have a higher relevant information
> density.  At least when compared with another index that has the
> same columns in it.

That really depends on the stats.   Such a choice would *not* be
appropriate if the < comparison was expected to return 1- rows while the =
condition applied to 15% of the table.

What is your STATISTICS_TARGET for the relevant columns set to?   When's
the last time you ran analyze?  If this is all updated, you want to post
the pg_stats rows for the relevant columns?

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

pgsql-performance by date:

Previous
From: "Karl O. Pinc"
Date:
Subject: Forcing use of a particular index
Next
From: Jacques Caron
Date:
Subject: Re: Forcing use of a particular index