Чего мне не хватает в PostgreSQL после MySQL.
Целочисленные типы данных. В MySQL самый маленький тип целого - TINYINT, занимающий в памяти всего один байт. В PostgreSQL меньше двух байт на целочисленное поле выделить нельзя.
Отсутствие беззнаковых целых. Если я знаю, что отрицательные значения у меня недопустимы, то было бы неплохо использовать бит знака числа для расширения его диапазона. В PostgreSQL, если тебе не хватает диапазона до 32767 включительно, то дальше обходиться двухбайтным полем SMALLINT ты уже не можешь и вынужден использовать четырёхбайтовое INTEGER. А как хотелось бы сидеть на двух байтах аж до самого числа 65535. Конечно это даёт возможность отказаться от отдельного поля "deleted" и помечать строки на удаление меняя номер строки на отрицательный. Но занимать от двух байт на каждую строку только для однобитового флага жаба душит. Тем более удаление отдельных строк используется далеко не во всех сценариях. И там, где скорость обработки запроса может стать узким местом, как раз строки скорее всего удаляться не будут.
Отсутствие SHOW CREATE TABLE. В MySQL набрав SHOW CREATE TABLE table_name; получаешь на экран готовую команду CREATE TABLE table_name (...); со всеми параметрами, которой была создана эта таблица. Или по крайней мере которой можно создать аналогичную таблицу. Т. е. свойства таблицы представлены в том-же виде, в котором ты или кто-то другой их писал. В PostgreSQL свойства таблицы можно получить только в табличном виде, причём не все. Например если на столбец было добавлено ограничение UNIQUE, создающее уникальный индекс по этому столбцу, то в описании таблицы будет виден только сам индекс. Тот факт, что индекс добавлен не отдельной командой CREATE UNIQUE INDEX, а является именно ограничением CONSTRAINT, из описания не следует. Как следствие попытка удалить такой индекс командой DROP INDEX приводит к ошибке с пояснением, что удалять надо не индекс, а ограничение столбца. Хотя это скорее относится не к серверной части, а к штатному текстовому клиенту psql.
Символьный тип данных CHARACTER (с постоянной длинной, дополняемый пробелами) судя по документации не даёт выигрыша в скорости. Даже может работать медленней. В MySQL он работает быстрей, чем VARCHAR именно за счёт того, что его размер фиксирован и известен заранее. Плюс редактирование данных в таких полях исключает фрагментацию таблицы, даже если данные немного меняют свою длинну в рамках указанного размера. Для полей с данными, близкими к фиксированному размеру, хотелось использовать его, а не VARCHAR, который ещё и дополнительно от одного до четырёх байт на хранение размера занимает. Хотя в PostgreSQL CHARACTER похоже тоже занимает. Т. е. CHARACTER там реализован как VARCHAR, а дополнение пробелами эмулируется для соответствия стандарту.
Конечно это не значит, что я брошу PostgreSQL. Здесь уместна аналогия с операционными системами. В Linux и MySQL удобства появляются быстро, но ценой меньшей продуманности. Во FreeBSD и PostgreSQL они придут потом, когда будут найдены решения всех проблем, которые потом могут вылезти боком. Ну и конечно развитие продукта зависит от его пользовательской базы. Чем больше пользователей, тем активней развитие. Но тем, кто выбирает, эта информация может оказаться полезной.
Несколько лет назад megagroup.ru делал и хостил брату интернет-магазин. Магазин никак не появлялся в поиске Яндекса. В дежурных автоматических уведомлениях от Яндекса было написано "сайт запрещён к индексированию в robots.txt", но в robots.txt запретов не было. За-то в коде страниц были вставки <!-- noindex --> и <!-- /noindex -->. Я тогда не понял, зачем разработчики сайта (веб-студия Мегагрупп) временно закрывали сайт от индексирования, но решил, что раз теги уже закоментированы, то теперь они мешать не должны. Яндекс тогда на мои вопросы так ничего внятного и не ответил. Постоянно кормил завтраками про подождите пару недель и всё станет нормально, сейчас сайт ошибок не возвращает
. А пару дней назад я случайно наткнулся в справке Яндекса, что он такие "закоментированные" теги распознаёт и не индексирует заключённый в них контент. При этом Мегагрупп периодически слал брату письма, что сайта нет в поиске и неплохо бы заплатить за "продвижение в поисковых системах". Бизнес у брата так и не вышел на режим и фирму он в итоге вынужден был закрыть. Потому, что студия оказалась подлой, а Яндекс безалаберным. А сейчас у Яндекса все ссылки "обратная связь" и "служба поддержки" ведут на страницы, не имеющие ни форм ни контактов, а только ссылки, возвращающие к непомогающим разделам помощи.
Страница Яндекса Турбо-страницы для вашего сайта примерно на пол часа подвесила мне браузер вместе с жёстким диском. Имел неосторожность зайти туда со включенными картинками и скриптами. И эти люди учат нас делать быстро загружающиеся страницы. Не говоря уже о том, что без картинок и яваскрипта не только нельзя воспользоваться большинством их сервисов, но и даже полистать справочную документацию.