можете тупо их убрать(distinct) понятно что результат не тот будет и сказать за производительность.

странно что вы не пришли при этом к переезду с амазона на что-то более человеческое

Дистинкт не сложная операция если суммарное количество записей не сильно больше количества уникальных записей, как в нашем случае.

Ну амазон не так плох, хотя это отдельный холивар.

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

амазон ужасен, и ужасно дорог, а еще там ужасно медленные диски

Вы правы, но таких попаданий не очень много. Коэффициент меньше двух.

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

Не затруднит, я надеюсь. ;)
PostgreSQL всё равно, записали Вы:

SELECT *
  FROM (
       SELECT *
         FROM (
              SELECT *
                FROM a_table
               WHERE col1 = 12 AND col2 = 'x'
              ) AS nested_query1
       ) AS nested_query2

Или:

SELECT *
  FROM a_table
 WHERE col2 = 'x' AND col1 = 12

Т.е. планировщик практически полностью игнорирует синтаксическую структуру запроса.
Т.е. обычно вложенные подзапросы подвергаются flattening  / pull-up (что фактически превращает 1-й запрос почти во второй), выполняется predicate pushdown (что перемещает условия из внешних запросов туда, где их наиболее выгодно выполнять), и сами условия деконструируются и переупорядочиваются так, как это выгодно.

не мешай человеку на Си программировать хардкор!
:)

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

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

SELECT *
  FROM (
       SELECT *
         FROM (
              SELECT *
                FROM a_table
               WHERE col1 = 12 AND col2 = 'x'
              ) AS nested_query1
       ) AS nested_query2

SELECT *
  FROM a_table
 WHERE col2 = 'x' AND col1 = 12

В этом вырожденном случае да, но в реальном запросе, когда Вы обрабатываете каждый результат подзапроса агрегатами и окнами, никакого flattening не случится.
Я говорю не теоретически, а по результатам того, что мы пробовали.

То есть умный планировщик исправит Вас, если Вы засунете в подзапрос что-то, что можно развернуть. А если нельзя развернуть, то сделает как написано.

Но pushdown всё равно может работать, кстати.

> Я говорю не теоретически, а по результатам того, что мы пробовали.

И вот это странно — потому что если Вам удалось сделать это просто с помощью подзапроса, тут, скорее всего, что-то не так (не всегда, да).

делать олап кубы на сях для пг - может не так уж плохо, может когда-нибудь эта контора создаст расширение для пг ))

ну как у них поиск в массиве на сях работает в sql я уже увидел.

там не должно быть массива, там должна быть карта (хэш-функция)

Так добрые люди из сообщества ПГ сделали все, чтобы писать расширения на C легко и приятно - АПИ шикарный.
И вообще - начал замечать - чем моложе персонаж - тем с Большим пафосом он произносит речи "надо делать по паттернам из такой-то книжки..."
Когда мы в это вникали, из книжек была только отЭРЕнная копия Assembly Language for the PC Питера Нортона, а большинство преподавателей вузов еще на свет не родились.
И при этом я не позволяю себе категоричны высказывания по по теме, в которой сам не попробовал и не разобрался.

🤦‍♂