Благодарю

Я так поле под номера телефонов - чтоб не соврать - за два года раза три расшиперивал под меняющиеся запросы бизнес-логики.
То ещё удовольствие под нагрузкой DDL-ем таблицу блокировать эксклюзивно.

Varchar () позволяет тебе максимум использовать длину 255 символов, 4 байта помоему, при этом если ты написал 4/255 то он уменьшит автоматически количество занимаемой памяти до такого значения которое занимает введенное тобой количество символов, если тебе надо больше чем 255 то будь добр используй text, ибо нехуй)

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

По поводу индексов посоветуйте пожалуйста 🙈 там весь пример на пастебин с таблицами, данными и запросами.

Меня очень смущает что на update запросах сложные where - нужно ли индексы там добавить и какие?
И в конце select есть, посоветуйте там как индекс сделать - составной или просто на все столбцы по одному?

Вот тут пастебин

> Varchar () позволяет тебе максимум использовать длину 255 символов

Да нет же.

CREATE TABLE x(
y varchar(1234567)
);
INSERT INTO x(y)
SELECT repeat('a', 100000);

text+CHECK в среднем лучше, чем varchar(N), потому что text — native string type для PostgreSQL, а CHECK позволяет выразить и другие ограничения, кроме "длина <= N".

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

а потом в логе

2020-08-22 04:13:06.090 MSK [10175]:  user=,db= sid=5f0c41eb.27bf 00000 LOG:  server process (PID 23426) was terminated by signal 9: Killed
2020-08-22 04:13:06.090 MSK [10175]:  user=,db= sid=5f0c41eb.27bf 00000 DETAIL:  Failed process was running: select maintenance.pr_run_job('J3');
2020-08-22 04:13:06.090 MSK [10175]:  user=,db= sid=5f0c41eb.27bf 00000 LOG:  terminating any other active server processes


что хотя бы примерно это могло быть?

255 длинна поля это не 4 байта

CREATE TABLE x(
y varchar(1234567)
);
INSERT INTO x(y)
SELECT repeat('a', 100000);

вставилось, всё ок

public> CREATE TABLE x(
               y varchar(1234567)
               )
[2020-08-22 11:42:09] completed in 504 ms
public> INSERT INTO x(y)
               SELECT repeat('a', 100000)
[2020-08-22 11:42:15] 1 row affected in 16 ms

select length(y) from x;

100000

я походу просто не понимаю всё таки)

Чего Вы не понимаете? ;)
То, что написал @yevhen_dmytrenko про длину в 255 символов — просто неправда, вот и всё.

Я имею ввиду зачем мне менять varchar(n) на text, я не буду потом менять длину столбца, особенно letter varchar(1), тут вообще не ясен профит от text

для этого вполне есть check

А что значит "привёл к kill -9"? Вы OOM killer имеете в виду?
Если да, это могло быть всё что угодно, в т.ч. "виноват" может быть вообще не PostgreSQL, просто он стал жертвой.
Лучше перенастроить сервер (OS) так, чтобы OOM kills прекратились, если его предназначение — быть сервером именно для postgres.

тут и не понятно зачем varchar

у меня недостаточно знаний чтобы про OOM killer  ответить

Этот вопрос можно задать и наоборот. ;)
И да, в  "letter varchar(1)" можно вставить как пустую строку, так и цифру — это точно правильно?