Ответ был на вопрос:

Данный функционал очень актуален для магазинов, которые продают одежду и обувь. Чтобы человек, зайдя в каталог товаров, мог выбрать, например, все кроссовки 41 размера и посмотреть, что есть в наличии, а не открывать 100 товаров и проверять его там.

Я делал фильтрацию по росту ползунком "от и до". В каждой комплектации был заполнен "рост от" и "рост до", а у товара выставлялось минимальное и максимальное значение роста для комплектаций в наличии.
Выводил в фильтр просто РОСТ.

   public static function ormAfterwriteCatalogProduct(array $params, \RS\Event\Event $event) {
        if (($params['flag'] == \RS\Orm\AbstractObject::INSERT_FLAG) ||
                ($params['flag'] == \RS\Orm\AbstractObject::UPDATE_FLAG)) { //Если это добавление 
            $min = 99999;
            $max = 0;
            $prop_rfrom = 89; //характеристика - ростовка от
            $prop_rto = 90; //характеристика - ростовка до 
            $prop_rostovka = 'Ростовка'; //характеристика - ростовка
            $product = $params['orm'];

            $offer_api = new \Catalog\Model\OfferApi();
            $offer_api->setFilter(array(
                'sortn:>=' => 0,
                'product_id' => $product['id']
            ));
            $offers = $offer_api->getList();

            foreach ($offers as $offer) {
                if ($offer['num'] > 0) {
                    $data = $offer['propsdata_arr'][$prop_rostovka];
                    if (isset($data)) {
                        $arr = explode('-', $data, 2);

                        if ($arr[0] < $min)
                            $min = preg_replace('/[^0-9]/', '', $arr[0]);
                        if ($arr[1] > $max)
                            $max = preg_replace('/[^0-9]/', '', $arr[1]);
                    }
                   
                }
            }
            if ($max > 0 && $min < 99999 && $max >= $min) {

                //выключаем ростовку от и до 
                \RS\Orm\Request::make()
                        ->delete()
                        ->from(new \Catalog\Model\Orm\Property\Link())
                        ->where("group_id is null")
                        ->whereIn("prop_id", array($prop_rfrom, $prop_rto))
                        ->exec();
                $proplink_table = \RS\Orm\Tools::getTable(new \Catalog\Model\Orm\Property\Link());
                \RS\Db\Adapter::sqlExec("INSERT IGNORE INTO {$proplink_table} (site_id, prop_id, product_id,  val_int, public, xml_id)
               VALUES (1,{$prop_rfrom},{$product['id']},{$min},0,'')");
                \RS\Db\Adapter::sqlExec("INSERT IGNORE INTO {$proplink_table} (site_id, prop_id, product_id,  val_int, public, xml_id)
               VALUES (1,{$prop_rto},{$product['id']},{$max},0,'')");
            }
        }
    }

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

На самом деле в одном из известных движков это реализовано, начинается на CS, но размеры там атрибутами реализованы.

Мне тоже интересно. Пересмотрел кучу движков интернет-магазинов, почти нигде нет такой функции как вывод числовых счетчиков доступных характеристик товаров. Например выбираю у футболок размер 52 и мне показывается, что таких футболок есть красного цвета 3 варианта, зеленого 1 вариант, а голубого 0.

Это, что на самом деле так сложно сделать раз нигде нет? Настолько эксклюзивная фича получается.

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

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

А сколько примерно запросов к базе генерируют такие фильтры, ну чтоб хоть примерно представлять нагрузку и всю ситуацию?

В интернете полно статей на эту тему, гуглите самостоятельно.

А сколько примерно запросов к базе генерируют такие фильтры, ну чтоб хоть примерно представлять нагрузку и всю ситуацию?

Это, что на самом деле так сложно сделать раз нигде нет? Настолько эксклюзивная фича получается.

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

Это, что на самом деле так сложно сделать раз нигде нет? Настолько эксклюзивная фича получается.

Сроки пока неизвестны, что будет в итоге тоже не раскрою, но работа идёт Всё инкогнито. Следите за обновлениями. Будет статья.

Скажите пожалуйста Александр, есть ли на данный момент решение этой задачи?