По-моему, здесь очень хорошо подойдут триггеры FOR EACH ROW.
aev
(Насколько я знаю count() при таких объёмах работает не очень быстро).

Никаких каунтов делать не нужно.
В триггере FOR EACH ROW:
Если запись вставляется, то update tr_category_stats set total = total +1; (или вставка новой записи с total=1)
Если запись удаляется, то смотрим на is_active и уменьшаем на единицу соотв. количество.
Если запись обновляется, то смотрим на изменение флага is_active и выполняем уменьшение/увеличение total/removed.


Если в таблице tr_email предполагаются массовые удаления/обновления, то можно (как пример) добавить дополнительную таблицу, в которой будет изменяться флаг перед такими массовыми операциями. А в триггере проверять этот флаг и если установлен, то ничего не делать.
И массовые удаления/обновления выполнять отдельной процедурой, без всяких триггеров.
То есть, схема процедуры примерно следующая:
1. Блокируем таблицу tr_email
2. Выставляем флаг, что начали массовую обработку.
3. Копируем во временную таблицу рабочую выборку из category_id и и количества. (То есть, если операция update tr_email set is_active=false where category_id in (2, 3, 6) and is_active=true, то выбираем предикат и вставляем во временную таблицу такое: select category_id, count(*) from tr_email where category_id in (2, 3, 6) and is_active=true group by category_id. Если некоторые записи из одной категории могут быть is_active=true, а другие is_active=false, то все усложняется...)
4. Делаем чего хотели (удаляем или обновляем).
5. Для каждой строки из временной таблицы делаем правильный update tr_category_stats.
6. Сбрасываем флаг.

Теперь со спокойной душой делаем коммит, и все продолжается как обычно.

Жаль, триггер нельзя задизэйблить, или я еще не знаю чего-то...

В общем-то, можно и на Statement-триггерах делать, наверно, но надо все еще раз хорошо оценить. Для обеспечения согласованности в этом случае, наверно, придется использовать уровень изоляции serializable.

2 centur: Это путь для смелых и продвинутых людей. ;-) Я в таблицах словаря предпочитаю не ковыряться, боюсь. ;)

2 аха:

Так кто ж спорит, можит и не лучше, а может даже намного хуже. Может, каунт у вас будет почти моментальным. ;)
Просто надо протестировать на конкурирующих транзакциях, чтобы убедиться, что в результате итоговые значения будут корректными. А можно проверить разные подходы и сравнить.

З.Ы.
аха
Или что изгиляться с недотыкомками полезней, чем пользоваться готовыми продуманными решениями
Эту фразу я понять не могу. ;-) О чем это вы?

2 aev & аха: (вдогонку)

Любые предложенные варианты нужно тестировать и сравнивать, только в сравнении (на реальных данных и в реальных условиях) можно определить, какой подход может оказаться лучше.
Доказывать ничего не собираюсь, зачем оно мне?


Удачи.