Причина происходящего, вероятно, в том, что руководство не видит оракловых спецов, с кем можно работать по оптимизации и решению прочих проблем, а спец по постгресу, наверное, есть на примете. Нет?
Подводных камней масса:

1. Невозможность коммитить транзакции в процедурах. Может, коммит в процедурах - это и плохой тон, но если это есть, то переделка ляжет на плечи клиентской части
2. pgsql достаточно демократичен по поводу использования левописных структур и типов данных. Чего будет стоить перенос оных в оракл, если таковые присутствуют... взять, к примеру, древовидный тип ltree, в котором многие любят хранить, скажем, адреса
3. вменяемого аналога оракловому партиционированию нет. Есть жуткий суррогат.
4. веселая отладка. Решение проблем с производительностью - это гребаная черная магия. Толковых инструментов для анализа нет, нет ничего похожего на механизм oracle events. Последний раз, когда сидел на 9.1, видел какую-то тулзу для юниксов, которая может выдавать хоть что-то, пригодное для анализа чтений, дисковой нагрузки, но по полноте дебажных данных сравнивать с ораклом нельзя. Для постгреса под виндой такой тулзы нет. Механизм решения проблем следующий: в голове программиста сидят 20 шаблонов, как делать хорошо и как не делать плохо. Он просто перебирает эти шаблоны и смотрит, какой подходит к его ситуации. Инструментария нет.
5. Если каким-то образом ваш проект на оракле завязан на изменения в ddl по ходу пьесы, то в постгресе вас ждет большой сюрприз - ddl там транзакционен, т.е. может откатываться. С блокировками, соответственно, ситуация обстоит по-другому.

Если вернусь с совещания в течение часа, допишу пункты 6 и 7 про оптимизатор.

В целом, postgres - классная СУБД для своего сегмента. На мой взгляд, если не оракл, то Postgres. Просто человеку, вырасшему на оракле, тяжело будет спускаться.