байта нетуЕсть ли у Postgres недостатки по сравнению с MySQL (innodb) ?
Ну вот хочется узнать хотя бы пару мест, где mysql существенно производительнее постгреса, при условии, что обе базы тюнили профессионалы. Какие кейсы так сказать. Чтобы заранее знать подводные камни.А вообще сравнивать производительность в отрыве от конкретного кейса и конкретных настроек - это глупость. Все зависит от миллиона нюансов.
Да, это удобно. Мутить что-то через триггеры - это хуже.В мыскле - ммм. Ну в нем upsert-ы есть.
С постгресом я только месяц работал, и не успел толком понять его недостатки. Кроме неудобности инструментов работы с ним.Если хорошо знаешь, в какую дырку подоткнуть мыскль, а постгрес видишь первый раз, смысла менять базу конечно нет.
begin;
drop table whatever cascade;
-- Постгрес: drop cascades to ...
-- пользователь: ой, бл..
rollback;
-- таблица на месте
Специальные функции, в т.ч. рекомендуемые в официальной документации, в основном нужны как обёртка над постановкой savepoint'а перед insert'ом. Если его не ставить, то возможна ситуация когда update ещё ничего не обновил, а последующий insert уже напоролся на запись, вставленную в параллельной транзакции. При этом текущая транзакция откатится целиком.Кстати, поскольку заговорили про UPSERT'ы , кто как решает данную проблему? с точки зрения того что код может быть перенесен с легкостью с pgsql на mysql например. пока что нашел это, вариант INSERT+UPDATE двух запросов как-то проще, чем функции специальные
поподробнее:Sad Spirit
мм... а если делать все в одной транзакции то такой проблемы не будет, или я что-то не так понял?
begin;
-- много-много операций
update что-то там;
-- если запись изменена - заканчиваем
insert что-то там;
-- перед этим insert'ом могла быть в параллельной транзакции вставлена запись
-- если insert вызовет ошибку, то откатится транзакция и откатятся "много-много операций"
commit;
http://www.postgresql.org/docs/8.2/interactive/ddl-partitioning.htmlЕщё в mysql есть нативный partitioning (в pg это можно на хранимых продцедурах сделать)