Быстро объясняйте, а то человек сейчас сделает глупость 😂

PostgreSQL 11 gives a nice feature that supports table-level dynamic setting TOAST_TUPLE_THRESHOLD, which is finally not statically compiled.

смотрите, есть такая таблица, знаю, там где массивы, это я пытаюсь избежать некоторых джоинов, На этой таблице уже есть несколько индексов, для сортировки 3 и для поиска GIN индекс, я чувствую, что ещё и запись будет оочень сильно страдать

Не давите на меня, я постгрю год активно не трогал!:)

Это вообще ничто, перестаньте думать о всякой ерунде. ;)

Premature optimization is the root of all evil.
        -- D.E. Knuth

эта оптимизация доведёт в могилу скоро преждевременная(

А Вы именно этим и маетесь!
Прекратите, серьёзно.

A page usually has the size of 8 KB. The size can be changed within certain limits (16 KB or 32 KB), but only during the build (./configure --with-blocksize). A built and run instance can only work with pages of the same size.

И вот уже потеряна возможность ставить PostgreSQL из дистрибутивов, репликации на дистрибутивные версии, и т.д. и т.п.
Нет, можно ещё как-нибудь "себе в ногу выстрелить", спору нет... ;)

Мне пофиг, у меня в основном Солярка

Зашел, увидел что сишники всё еще конфигурят билд вместо возможности конфигурировать артефакт и zaplakala

возьми эластик уже

Ну а многим не "пофиг".
И зачем подобные советы давать вообще без объективных причин? ;)

+100
Такое впечатление, что где-то есть книга "мифы, легенды, и худшие практики реляционных СУБД", которую читают "оптимизаторы"... и верят и следуют каждому мифу и легенде, и аккуратно реализуют каждую из худших практик. ;)

а как реализовать каждую из ЛУЧШИХ практик тогда?)

Половина инфы в таблице вообще к итему не относится, типа сколько раз пост добавили в закладки, сколько коментировали, это все инфа не связанная с постом и выбирается другим путем, если бы вы преждевременно не оптимизировали, то не было бы кучи столбцов у поста... часть инфы вообще отдельной связывающей таблицей должны быть, то что вы айдишники записали как кеш в таблицу сделало только хуже по факту, потому что джоина вам не избежать, а вот массив работает хуже чем доп таблица, учитывая что при правильных индексах эти джоины будут точечные, т.е. в итоге пол таблицы у вас типо оптимизация, а на самом деле вы дурью маетесь, как вам и сказал Ярослав. 😄

Не "заморачиваться" преждевременной оптимизацией на таких смешных объёмах, в первую очередь.
А если у кого-то обсессивно-компульсивное расстройство проектирования, хотя бы генерировать тестовые данные и проверять. ;)

нужен поиск - строишь модель под поиск
нужен классический доступ - строишь классическую модель
нужно и то, и то - строишь две модели

и самое главное: нужно MVP - делаешь MVP, все остальное потом