Re: "Overlaping" indexes

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: "Overlaping" indexes
Дата
Msg-id 1075749471.308.105.camel@jester
обсуждение исходный текст
Ответ на Re: "Overlaping" indexes  (Tomasz Myrta <jasiek@klaster.net>)
Список 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 по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: "Overlaping" indexes
Следующее
От: "Kevin Barnard"
Дата:
Сообщение: Increasing number of PG connections.