Задачка:

Есть таблица с 15'000'000 записей, двумя нужными индексами и триггером, модифицирующим другую таблицу в 100 раз меньшего объема. Большая таблица практически постоянно обновляется, плюс есть десятки гетерогенных запросов к ней, в т.ч. из других схем (вследствие чего ее вынос на отдельный сервер затруднен). БД — PostgreSQL 8.x. Область использования — OLTP-приложение. Нужно ускорить работу с этой таблицей.

Варианты:
— проксирование запросов на несколько БД (plproxy)
— репликация (Multimaster или Master-Slave, модифицируем на одной машине, читаем на другой) — Slony-I, pgcluster
— балансировка нагрузки + Master-Slave репликация всей БД (pgpool)
— table partitioning (очень небольшой прирост, даже при нормальном распределении на этих объемах)

Что бы вы могли посоветовать из того, чем пользовались сами?

Здравствуйте, beldmit, Вы писали:

B>Задачка:

B>Есть таблица с 15'000'000 записей, двумя нужными индексами и триггером, модифицирующим другую таблицу в 100 раз меньшего объема. Большая таблица практически постоянно обновляется, плюс есть десятки гетерогенных запросов к ней, в т.ч. из других схем (вследствие чего ее вынос на отдельный сервер затруднен). БД — PostgreSQL 8.x. Область использования — OLTP-приложение. Нужно ускорить работу с этой таблицей.

Чтобы знать, что нужно оптмизировать, нужно знать что собственно говоря тормозит.
а) Тормозят insert/update/delete
б) Тормозят запросы по табличке

В любом случае, нужно больше информации... Например, все ли запросы попадают в индексы, каково в среднем их количество за период времени, какой в среднем %% записей они выбирают...
Насколько широка сама табличка и насколько широкие по ней построены индексы...
Какие операции модификации преобладают, среднее их количество в единицу времени...
Насколько важна для запросов актуальность данных (т.е. можно ли например пускать запросы по snapshot'у 5 минутной давности ли нет)...

Это первое, что пришло в голову. Без этого давать какие-нибудь рекомендации имхо смысла нет...

ЗЫ: А железо-то адекватное задаче?