Вопрос про varchar

https://www.postgresql.org/docs/10/static/datatype-character.html

https://dev.mysql.com/doc/refman/5.7/en/blob.html

LONGTEXT | 4,294,967,295 (232−1) bytes = 4 GiB

😂

В SQLite тоже не нужно никаких varchar задавать 🍿

А, вы про mysql. Я думал, что postgres, раз эту фразу цитируете. С longtext у mysql другая ситуация, этот тип хранится отдельно от таблицы и работают соответственно медленнее, чем varchar, с сортировкой и индексированием отдельная история, ну не мне вам рассказывать, разные вещи.

В postgres большие текстовые данные хранятся отдельно "Very long values are also stored in background tables so that they do not interfere with rapid access to shorter column values.".

В mysql text хранится отдельно, но в целом более грамотно чем varchar, именно из-за отдельности и мы бы не сказали что он работает медленнее, в некоторых ситуациях конкретно быстрее.

зато в постгрессе коннект к базе медленный, приходится проксировать его . Беее :)

Stek, а зачем постоянно подключаться? Подключился один раз при старте и подключение в пул. Если приложение такого не умееет, то pgpool. Это вообще всех БД касается.

Оптимизайка, честно, не знаю. Но сколько вижу разного рода фреймворков на разных языках - все стараются избегать постоянных соединений.

pgpool и есть фактически тот же прокси. Плюс для постгрес настройки куда сложнее, в обслуживании сложнее. Имхо ради varchar смена базы того не стоит :)

У меня Мариа ДБ 10.2

Изменение только одного поля из 8 с 255 на 64 уменьшило вес таблицы с 205 мб до 199.

Изменение 7 полей из 8 на varchar 32 или 64 - увеличило вес таблицы до 236 мб. (эта мистика мне не понятна) :))

После оптимизации таблицы - 204,5 мб.

Вывод: зависимости веса таблицы от длинны поля не найдено :))) так и запишем

Dram, вы не вес, а скорость выполнения запроса с разной длиной varchar проверьте, если это поле участвует в условии where, group by или order by. Особенно если в плане по этому полю предлагается filesort.