We begrudgingly use Solr instead (we started before ES was really a thing and haven't found a need to switch yet)
When you get more than about two different types of filters (e.g. types of filters could be 'tags', 'categories', 'geotags', 'media type', 'author' etc), the combinatorial explosion of Postgres queries required to provide facet counts gets unmanageable.
For example, when I do a query filtered by `?tag=abc&category=category1`, I need to do these queries:
- `... where tag = 'abc' and category_id = 1` (the current results)
- `count(*) ... where tag = 'def' and category_id = 1` (for each other tag present in the results)
- `count(*) ... where tag = 'abc' and category_id = 2` (for each other category present in the results)
- `count(*) ... where category_id = 1`
- `count(*) ... where tag = 'abc'`
- `count(*)`
There are certainly smarter ways to do this than lots of tiny queries, but all this complexity still ends up somewhere and isn't likely to be great for performance.Whereas solr/elasticsearch have faceting built in and handle this with ease.
counting by groups is still relatively expensive though in postgres; I built an implementation which uses estimate counting (via query planner) for larger buckets, and exact counting for only smaller buckets, but my use case allowed for some degree of inconsistency.
That said, simonw has been on the case[2] demonstrating an implementation of that using Django and PostgreSQL.
[1] - https://en.wikipedia.org/wiki/Faceted_search
[2] - https://simonwillison.net/2017/Oct/5/django-postgresql-facet...