MultiLevelSelect Field 7.4 -- Problem with Filter numbers

here a query which will get the filter numbers per for a level on my system in 0,06 sec

SELECT

    count( * )  AS "Number",

    (

        SELECT

            `hsb0a_js_res_field_miltilevelselect`.`name`

        FROM

            `hsb0a_js_res_field_miltilevelselect`

        WHERE

            `hsb0a_js_res_field_miltilevelselect`.`id` = `hsb0a_js_res_record_values`.`field_value`

    ) AS "Name"

FROM

    `hsb0a_js_res_record_values`

WHERE

    `hsb0a_js_res_record_values`.`section_id` = 1

AND `hsb0a_js_res_record_values`.`field_key` = 'k0362d23b33c4bf360668cbc9a59e7d96'

AND `hsb0a_js_res_record_values`.`value_index` = 0

GROUP BY

    `hsb0a_js_res_record_values`.`field_value`

ORDER BY name

Another question comes up now ... as of now the filter numbers which are displayed, representing the total number of possible choices.

Should'nt they be computed based on other "influences" dictated by the record itself like expired, unpublished etc?

Also if i select first a category and start then choosing the filters, the numbers might be totally different.

Overall i would be confused, if the filter number shows me for example 120, but when i execute the query, only 34 will come out, since i called the query from a category.

Should'nt they be computed based on other "influences" dictated by the record itself like expired, unpublished etc?

ALthough we have discussed this already I'll summarise it here in case someone may be interested in answer.

yes to get actual number is nice. And we would love to do it. But we afraid that this query complexity will sacrifice Cobalt speed. Because if we go this way we have to calculate indexes not only in category but also apply all current filers to every filter. That even sounds overwhelming :D.

I als made some changes so I think it should be quick in upcoming version.