> А специфика конкретных приложений затачивается уже указанием индексов. Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь, индекс, и ничего кроме" - очень даже нужны хинты/форсирование.
> В MySQL часто. В PostgreSQL существенно реже.
"Часто", "реже" - это всё относительно, и зависит от приложения / структуры БД. У меня есть большая табличка, аналитическая выборка из которой ломает шаблон оптимизатору хоть MySQL, хоть MSSQL, хоть Оракла. Просто потому, что все три берут самый очевидный вариант плана запроса, который совершенно неоптимален с точки зрения доступа к диску. И переструктурировать ее некуда - там явных внутренних связей просто нет, + символьные поля переменной длины. С форсированием конкретного индекса (раза в два больше строк в скане, зато на порядок меньше время выполнения) же вся аналитика бегает очень неплохо.
> Да сколько угодно. Проблема только в том что MySQL все еще хуже
> по фичам чем PostgreSQL ивсе так же плохо держит нагрузку.
Тут бы неплохо пруфлинк-таки, потому что из того, что я на форумах вижу - ситуация прямо обратная.
> Какого еще длительного блокирования? Ну пишу я себе там в потоке ни
> у ладно.
Когда делаешь START TRANSACTION, и начинаешь писать данные пачками - блокируются части индекса. Ровно до момента COMMIT. Поэтому параллельные записи, затрагивающие те же части индекса - уже не пройдут, и будут ждать выполнения твоей транзакции. А до момента COMMIT может пройти много времени.
Поэтому иногда выгоднее отсутствие явных транзакций, и выполнение по 1 команде записи на транзакцию. Например при высоком параллелизме обновления одних и тех же таблиц. Zabbix в его нынешнем виде - как раз тот случай.
Хотя - да, его бы переписать с прямой записи в таблицы на каждый чих на очередь обновления - и он нормально бы с транзакционностью ужился, и проблем с производительностью стало бы меньше. Подвижки в этом направлении там уже есть, но пока что не везде.
