del хабр чет подвисает, задублировалось

В вашем примере заведомо в проигрышной позиции JSONB т.к. для него вы выбрали GIN индекс, тогда как для EAV hash. Если я правильно понял ваш юзкейс.

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

Но опять таки все зависит от исходных задач и профиля нагрузки на БД — серебренной пули не бывает.

Современный PostgreSQL имеет JSONB. Который мне кажется будет предпочтительнее к использованию на текущий момент, чем EAV.

Так все таки JSONB или не бывает? Мой вопрос возник именно потому, что изначальное утверждение было достаточно безапелляционным, поэтому мне стали интересны какие-то подтверждения этого тезиса. Потому что на горизонте есть подобного рода задачи.

Jsonb поддерживает не только GIN индексы (btree и hash также поддерживаются).

Тип jsonb также поддерживает индексы btree и hash. Они полезны, только если требуется проверять равенство JSON-документов в целом. Порядок сортировки btree для типа jsonb редко имеет большое значение, но для полноты он приводится ниже:

В вашем вопросе будет сравниваться производительность индекса с индексом без относительно кто был источником данных (EAV или JSONB — не важно).

Именно. В этом и суть вопроса. Но я на него все еще не получил ответ. Есть ли у вас бенчмарки, которые подтверждают ваши тезисы?

Производительность EAV схем всегда была ключевой проблемой.

Современный PostgreSQL имеет JSONB. Который мне кажется будет предпочтительнее к использованию на текущий момент, чем EAV.

Из этих утверждений я делаю вывод, что вы считаете реализацию указанной в статье логике через JSONB производительней, чем через EAV. Я прошу вас чем-то подкрепить это утверждение и в качестве примера дал вполне конкретный юзкейс.

Я знаю, поэтому я и указал в скобках GIN. мой вопрос не про возможность, а про производительность.

А есть сравнение производительности поиска по json (через GIN) и поиска в EAV (где, полагаю, достаточно какого-нибудь хеша)? Ну т.е. например задача, найти все сущности у которых не заполнен (отсутствует значение) атрибут X.

Чаще всего то, что каждый вызов резолвера независим. И нужно либо делать предварительный парсинг (что в целом сводит на нет всю полезность резолвера, т.к.в этот же момент можно и в реквест заинжектить все что нужно), либо парсить в каждом резолвере (что как бы зачем).

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