> нет статистики
На любые корреляцыи в joinах, в том числе в одной таблицэ, например, на значения avpair.

> нельзя сделать статистику

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

>стастистика плохо собирается

Тут, на самом деле, трудно отклассифицыровать от первого пункта: всегда можно сказать, что в постгрес такого нет, потому это в принцыпе в текущей версии невозможно, или наоборот, что такого нет пока что только в текущей версии -- то есть постгрес плохо её собирает временно.

(сорри, тут преждевременно отправилось).

Но примеры: это отдельные значения, которых мало (например, в таблицэ первая тысяча самых частых -- это десятки тысяч вхождений, с соответствующими проблемами. Вопросы по массе значений, которых по паре штук и по которым можно цыклы устраивать -- но статистика этого не знает). Это значения, которые приедут в забинжэнных параметрах или суб-селектах -- и про которые планнер тожэ не знает распределения, а я-то, возможно, что и знаю. Это всякие близкие группы значений, такие как "вокруг такого-то числа" или "вокруг такого-то города по координатам" (во всяком случае, я пока что не вижу возможности такой группировки в статистиках, возможно, что что-то пропустил).

Это attribute-value pairs, построение RDBMS, в которой у какого-то отношэния есть неограниченное количество атрибутов и значений, и которые хранятся в отдельной таблицэ.

То есть типичнейшая ситуацыя: магазин всякой техники, у разных товаров кроме артикула, фоток, цэны и веса есть всякие "число rpm", "максимальная частота", "чипсет", "можность в Вт", "леска для резания", "диск для резания", "привод на колёса", "бензиновый двигатель", "4-тактный", "2-тактный",  "пластиковый корпус", "объём в литрах", "оцинковка" и прочее.
Таких атрибутов можэт быть суммарно много тысяч. Пихать их все в разные колонки (атрибуты) отношэния -- просто смерти подобно, хотя бы потому, что списки атрибутов дополняются по-хорошэму каждый месяц.
Один из распространённых (и правильных с точки зрения реляцыонной теории) вариантов -- хранить их в дополнительно таблицэ атрибутов, ну там ссылка на таблицу товаров, атрибут, значение. Это и есть attribute-value pair (иногда -- key-value pair, kvp).
Поиск по коррелированным атрибутам в таких случаях имеет нюансы.
Замечу, что сейчас всё большэ такого складывается в json в основной таблицэ, но это вроде как денормализацыя, и, что важнее -- поиск по большым json тожэ имеет нюасны.

Такое лучше, как мне кажется, где-то в hstore или jsonb хранить.

Думаю на это можно получить статистику, создав индекс по полям jsonb. Но это так себе, да, создавать индексы там, где они, возможно, не нужны.

И, кажется, статистика дефолтная умеет собираться по таким полям, но она, да, скорей всего даст не то, что нужно (если я не ошибаюсь, то это most_common_elems в pg_stats и их частота most_common_elem_freqs).

> Это значения, которые приедут в забинжэнных параметрах или суб-селектах -- и про которые планнер тожэ не знает распределения, а я-то, возможно, что и знаю.

Вы написали много теста, Спасибо. Вот только я не всё понял.
Если в данном моменте вы описываете кейс, где есть подзапрос, результатом которого является число, а потом это число подставляется в фильтр другого запроса, после чего планер не может понять статистику, то это так, да. Но в этом случае как раз лучше разделить запрос на 2, тогда планер сможет правильно спланировать такой запрос.

> например, на значения avpair

На это есть CREATE STATISTICS, которые могут несколько улучшить положение. Но вообще, так пользователям avpair (EAV) и надо. ;)

> невозможных для хранения размеров вне датасета, таким образом, никакая разумная статистика не покажэт

Подчёркнутое, строго говоря — неправильный вывод (для некоторых параметров есть (методы построения) robust statistics), и те, что можно, используются в PostgreSQL.

> это отдельные значения, которых мало

К счастью, обычно достаточно этого знания, во-первых; и overestimation не так страшна, как underestimation (т.е. планы получаются только немного хуже, обычно), во-вторых.

> Это значения, которые приедут в забинжэнных параметрах

Хмм... что с ними не так? Там редко бывает что-то, у чего вообще есть распределение (это почти всегда скаляры).

> или суб-селектах

Если они преобразуются в JOINs, то оценки производятся по общим принципам.

> такие как "вокруг такого-то числа"

Так гистограммы (если хватает детализации), нет?

> или "вокруг такого-то города по координатам"

Тут уже хуже, да (но см. CREATE STATISTICS).

Походе в create statistics нужно завозить возможность собирать статистику по полям jsonb и по массивам.

Сейчас читаю синтаксис и там написано, что create statistics можно сделать только минимум на 2 столбца (меня это шокирует o_O).

Я про коррелированные поля. То есть вот нужно мне сразу пара атрибутов, и я знаю что там будет от силы пять результатов... А планнер -- нет, он берёт среднюю селективонсть для каждого (ну там, 1/100), получает в своих фантазия сотни и тысяч строк.
Или наоборот, глубоко коррелированные значения. Штук пять. Планнер считает, что каждый мне отберёт 1/100, итого -- от силы одна запись останется. А у меня наоборот тысячи таких записей.

А, для этого есть create statistics

И да, с функцыональными статистиками тут пока тожэ всё плохо, так что json как-то от этого не спасает.

Это называется EAV, и никакого отношения к реляционному моделированию не имеет.

> просто смерти подобно, хотя бы потому, что списки атрибутов дополняются по-хорошэму каждый месяц.

Странно, а я знаю (видел), что это работает. Мне это, видимо, неоднократно приснилось? ;)

> Один из распространённых (и правильных с точки зрения реляцыонной теории)

Распространённых антипаттернов, да. И это нереляционная модель, правильной с т.з. реляционной теории она быть не может.

Не в одной строке коррелированные, а в JOIN.

>Странно, а я знаю (видел), что это работает. Мне это, видимо, неоднократно приснилось? ;)

Что  именно работает? Нормальный список полей универмага в таблицэ?
Извини, не верю.

В конторе по продажэ зажыгалок -- запросто, конечно. Сотня полей, и те мерчендайзер по сути ленится заполнять.
В каком-нибудь dns-shop -- нет, это смешно.

> (если хватает детализации), нет?

С детализацыей часто нюансы, да. Ну, примерно те жэ, как с geospatial -- равномерное распределение разумного размера не показывается большынства особенностей.

Если вы их join-ите, то наверное нужно тогда иметь хотябы foreign key constraint, тогда планер тоже будет оценивать.

Вообщем тут нужен пример.

Чувствую, что далее вообще имеет смысл только примеры приводить, так как уж слишком абстрактно.

>Распространённых антипаттернов, да.

(Пожав плечами) И какие варианты?

Про json знаю, это во-первых куда менее реляцыонно (ужэ не в 1НФ), во-вторых -- имеет примерно столько жэ проблем с оцэнками планов запросов.
Хотя сейчас чаще используется, да.

Ещё?

> Нормальный список полей универмага в таблицэ?

Да.

> Извини, не верю.

А мне всё равно, верите Вы или нет, извините. Я видел (в т.ч. участвовал в разработке) и знаю, что это работает.
Можете поискать в интернете описания подобных реализаций, если хотите.

> В каком-нибудь dns-shop -- нет, это смешно.

Да, видел и именно в таких shops. "Смех" — это не аргумент, кстати.
В сторону: меня одного особенно бесит, когда меня пытаются убедить в том, что то, что я видел своими глазами, "невозможно"? ;)

"Широкие" таблицы или 5/6NF (обе с DDL).

И да, EAV — тоже не 1NF.

Ну, ОК, И сколько атрибутов в итоге это всё потянуло? И в каждой таблицэ и суммарно?

Ну я в данном случае с EAV согласен, что он портит распределение/статистику и ТОЛКЬО по этому его делать не стоит.