и под виндой и под линуксом все робит нормально. Если у тебя не много народу

Nitro_Junkiesigmov,

3. Ни MSSQL ни PGS не любят временные таблицы. Временные таблицы - это костыль от 1С для совместимости с файловой БД.

Да конечно... А куда по вашему нужно временные данные (на время транзакции или сессии пользователя) складывать? Каждый раз в запрос вставлять? Точно не знаю как у MSSQL но у postgres'а с временными таблицами все более менее ничего (если уметь ими пользоваться, см. ниже)

Сама же postgres как база напоминает автомат калашникова работает надежно, но умеет то что умеет, если хочется чего-то больше надо изгаляться. Из того что навскидку помню:

1. Predicate pushdown'ов нет как класса. То есть да, во вложенные запросы надо всегда проталкивать внешний контекст. Строго говоря у MS SQL predicate pushdown хоть, и есть но тоже сильно примитивный.
2. Постгрес на каждое соединение создает поток и если их не pool'ить (а если хранить данные во временных таблицах их не получится эффективно pool'ить), то память начинает медленно но верно утекать. Решается демоном который скорит соединения и периодически их перестартует (не сильно тривиальная задача, но решается).
3. Достаточно часто косячит со статистикой (так как оптимист неимоверный), то есть если чего не знает сразу считает selectivity не корреллированной, то есть сильно уменьшает кол-во записей и здравствуй nested loop на пару десятков миллионов записей. Особенно это касается вложенных подзапросов. Лечится материализацией подзапросов + в 10 beta вроде появилась cross column статистика.
4. Он конечно версионник от рождения, что очень большой плюс по сравнению с MS SQL (хотя в 1С забили на все блокировки СУБД и переложили ответственность на 1С-программиста, не знаю кто там так сильно ударился головой принимая такое решение), но сделан он не так как оракл. Если последний хранит последнее состояние и лог отката, то постгрес хранит все версии непосредственно в таблице. Это во первых все же немного менее эффективно в не сильно конкурентной базе (но это не страшно), но хуже когда есть часто обновляемые таблицы (а это практически всегда) и вдруг зависает какая-то транзакция на долгое время. Это останавливает autovacuum (очистку неактуальных версий), и часто обновляемые таблицы (если работа идет с одним диапазоном данных скажем за сегодня) начинают очень заметно тормозить. И вообще с vacuum'ами есть определенный гемор (нужно периодически делать VACUUM FULL'ы и соответственно следить за долгими транзакциями)
5. Есть приколы с кластеризацией, а именно то что в базовой поставке slave по сути блокировочник (что конечно адский ад, и одна из причин возврата uber на mysql). Хотя возможно есть альтернативные реализации.
6. Ну и куча мелкой фигни вроде того что не поддерживает FULL JOIN по сути приходится UNION'ами обходиться (а там проблемы с округлениями) и т.п.

Честно говоря не знаю как 1С разбирается со всеми этими проблемами (возможно просто ORM'ит), но считать что просто взял и сменил одну СУБД на другую это мягко говоря весьма наивно.
какой сменить? люди уже лет по 10 живут