Re: "Overlaping" indexes - Mailing list pgsql-performance

From Rod Taylor
Subject Re: "Overlaping" indexes
Date
Msg-id 1075749471.308.105.camel@jester
Whole thread Raw
In response to Re: "Overlaping" indexes  (Tomasz Myrta <jasiek@klaster.net>)
List pgsql-performance
On Mon, 2004-02-02 at 13:43, Tomasz Myrta wrote:
> Dnia 2004-02-02 19:30, Użytkownik scott.marlowe napisał:
> > Not entirely, since it only has to sort two columns, it will be smaller,
> > and will therefore be somewhat faster.
>
> Can you say something more about it? Will it be enough faster to keep
> them both? Did anyone make such tests?

You can actually come up with test cases where both indexes are useful.
The three column index will have more data to sift through. That said,
having both indexes used means there is less ram available for cache.

The biggest mistake I see is people doing everything they can to
optimize a single query, then they optimize the next query, etc.

When you consider the entire set of queries, those two indexes are very
likely to slow select throughput down due to increased memory
requirements and the system hitting disk a little more often.

It's similar to the mistake of benchmarking a set of 1000 row tables and
optimizing memory settings for that, then using that configuration on
the 10M row tables in production.



pgsql-performance by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: "Overlaping" indexes
Next
From: "Kevin Barnard"
Date:
Subject: Increasing number of PG connections.