ДрагаЕсть вопрос, скорее даже на проектирование БД...

Суть, есть некая расчетная система, СУБД выбран Postgresql.
С определенной периодичностью данные попадают в табличку (в основном update) и затем через систему триггеров кучу всего изменют (тарифы, балансы и прочую зависимую информацию).

Табличка - это по сути счетчики потребления. Планируемое кол-во записей в таблице порядка 3-5 млн. При этом за каждое обновление изменяться будет порядка 50-100тыс.записей... несколько раз в час. Данные там иерархические. Хотя иерархию можно жестко порезать до 3-5 вложений.

Вот.. Поскольку Postgresql субд версионная, то имхо ему поплохеет от такого масштаба изменений.

Вопрос собственно по ньюансам проектирования субд и разнесения информации по таблицам, плюс вопросы по скорости обработки всей этой информации, периодичности запуска аналайзера и вакуума и прочего.

Если кто-нибудь пожелает поделиться своим опытом, буду рад выслушать.
Назови мне хотя одну СУБД, которая будет от радости танцевать при таких объемах :)
Если честно, то еще не успел поработать с такими объемами в postgreSQL - было дело в myql - база была более 150 метров, так вот:
Был атаблица items с товарами, где было одно поле типа text. Когда в таблице стало данных до указанного мной объема ее надо было переработать в php (в Mysql такую обработку в принципе сделать невозможно) и было там одно поле "av" - тип Integer - там были значения 0 или 1 - в зависимости от того,было ли поле уже обработано, или нет. Так вот, когда я писал обработчки (он должен был из этой таблицы в другую по своим правилам вытащить данные - конкретнее - описание товаров выдрать из html кода страниц по жутким правилам) Короче, когда я делал откат к первому - то есть запрос типа update ... set av=0 то он обрабатывался более 30 секунд :). Конечно, ситуация в postgreSQL явно была бы не столь плачевная, но все же...
Отсюда единственное, что я могу (исходя из своего опыта) подсказать - Если сущность(объект) имеет множество параметров состояния(считай полей в БД) то лучше их разбить по нескольким таблицам - желательно - по частоте применения. То есть, те, с которыми работаешь достаточно часто - 1 таблица, те, с которыми пореже - во 2-ой. Идеальный вариант - так сказать разбить по таблицам на основе представлений. То есть - к примеру - список товаров: здесь у товара краткое представление - или просмотр товара - ту полное представление - которое будет вызываться реже, чем краткое, следовательно...
Что еще тебе могу сказать - в этой ситуации тебе стоило бы применять частичную деструктуризацию данных. Иными словами - хранить наиболее используемые данные в нескольких таблицах, чтобы:
1. уменьшать число обойденных за раз таблиц (то есть реально обходиться одним запросом, а не несколькими)
2. Стараться сделать так, чтобы чтобы для этих данных соотношение select/update было максимально.
Да, и еще перед проектированием напиться - лично мне помогает %)
Вот в принципе и все что я могу тебе посоветовать