romy4

не делать напрямую insert, а через хранимку?
делать инсерты во временную таблицу для каждого приложения и мерджить в основную? в свою можно сколько хош вставлять, но из неё мерджер проверяет таймстемп и флаг
lock table подвешивает соединения

> Если ли большой выигрыш в производительности между enum и small int?
Есть выигрыш в логике от подхода с enum, тип удобно использовать как сущность в функциях.

лучше сохранить путь к файлу
а файл всегда хранить на жёстком
как вы представляете себе отдачу этого файла в браузере?

сохраняйте его в темп таблицу и используйте сколько угодно раз до закрытия соединения

да полно. heidi, sqlnavigator, navicat и тд

И так вопрос: какого художника, индекс перестал использоваться?
малевича

А где именно у вас проседание производительности?
0.003 ... 0.015 ... 0.012
это ни о чём не говорит. Если б везде было 0.015, а вдруг 1.15, то уже можно начинать искать причину.

Чтобы сортировать по полю, надо сперва выбрать поле, а оно у вас не выбрано © матроскин
используйте группировку

а вообще SELECT DISTINCT ON(field_1, field_2), field_3 FROM table_1 ORDER BY field_3

Если данные не моноширинные (числа и строки одинаковой длинны), то удаляя их получаете сильно дефрагментированную базу. Получится, что данных мало, а база большущего размера. Чтобы это избежать, необходимо делать её оптимизацию, а это очень и очень затратно и даже недопустимо на нагруженных базах. Поэтому, решением стаёт поле del. А ещё хитрости в виде партиций и т.д.

условие WHERE?

смешной размер. любую брать

MW очень даже подходит, ящетаю

Можно почувствовать разницу используя PSQL и Lua

Как это вы не знаете про JOIN?
> в виде JSON объекта.
делайте это на принимающей стороне

сверху не по стандарту json, так что вам postgres всё верно возвращает. переделайте, чтобы всё воспринималось по стандарту

ну тут пальцем в небо потыкать можно будет долго
1. нагрузка на винт? проверить. свапинг
2. наличие ключей на полях
3. найти кто "ест" память