> This article explains in-depth why calculating facets is not practical in > pure SQL: http://www.kimbly.com/blog/000239.html -> "The problem is that SQL isn't really capable of expressing set intersections."
But this article is not applicable to described use case: we are _faceting_on_filtered_query_results_only_, and filters are defined by facets (same as). - no need to count docset intersections in this specific use case. Just execute 20 SQL queries with filters (if you have 20 'foreign keys' for an entity). Performance is like [log(n)] where n is index size... with SOLR, it is linear, it is not log(n)... Same with SOLR vs. Lucene, standard Lucene queries "filter1:value1 AND facet2:value2" ... "filter1:value1 AND facet2:value99" are functionally the same as SOLR faceting (99 docset intersections in RAM) and (sooner or later) implementation and performance will be similar very close (Lucene vs. SOLR)...
