очень много колонок в таблице, и есть текстовые, допустим мы в поле храним Дескрипшн чего либо - это зачастую 1000 + символов может быть, и считай, char - 1 байт - 1000 символов - 1000 байтов, и таких полей ещё 2-3, допустим json храним либо массив, и уже вылезаем за дефолтных 2КБ для тоаста, а дальше тоаст по умолчанию сначала сжимает эти данные до 2КБ и если не получается сжать, создаёт новую таблицу у себя под капотом, где хранит ссылку на оригинальную таблицу, вот когда 2К+, то уже следует смотреть стратегию, как поступать постгресу в случае оверсайза

кстати если ты на 100% уверен, что колонку не требуется сжать, можно выбрать стратегию, которая позволяет не использовать сжатие для колонки, но с этим осторожно, т.к. если всё-же сжатие потребуется, то будет ошибка

там оочень много подводных камней с этим постгресом)

Мы такие большие строки не храним даже)

чиселок много, да, но не на столько, чтобы по ширине не влазило

а я храню, по-этому задолбался проверять, какая стратегия лучше/ хуже, в итоге остановился на дефолтной ))

ну числа, это маленькие данные, до тоаста не дойдёт дело

индексы тоже много веса придают, если есть они у вас

без индексов никак)

а данных много, или не очень?

пара терабайт

без индексов никак))

клиент пожелал иметь аггрегацию данных меньше, чем за секунду)

кстати можете сделать ещё реиндексацию, это тоже вроде бы уменьшает вес

ну да < 1с - основное правило отдачи данных)

у нас админ это автоматизирует сейчас, я не знаю на каком этапе, возможно уже готово все

и перед тем как проводить манипуляции над всеми данными, я по ним вакуумом прохожусь

пылесосишь таблицу получается))