# Slowness in percolator 7.2 **URL:** \ **Category:** Elasticsearch\ **Created:** [September 19, 2019, 3:35pm UTC](https://discuss.elastic.co/t/slowness-in-percolator-7-2/200256 "2019-09-19T15:35:09Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![Faiz\_Ahmed\_Mushtak\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/faiz_ahmed_mushtak_h/32/47387_2.png) [@Faiz\_Ahmed\_Mushtak\_H](https://discuss.elastic.co/u/Faiz_Ahmed_Mushtak_H)\ **Post date:** [September 24, 2019, 2:01pm UTC](https://discuss.elastic.co/t/slowness-in-percolator-7-2/200256/6 "2019-09-24T14:01:41Z")
@Daniel_Penning we've found the root cause of our problem > [@How does PercolatorQuery work when query extraction failed](https://discuss.elastic.co/t/how-does-percolatorquery-work-when-query-extraction-failed/200884): > > Let me explain you our percolator architecture Our percolator docs look like this { "domain": \<\>, "query": { .. } } We have around 100K percolators registered. The number of percolators between domains can vary a lot. Whenever we percolate a document, we want to percolate only against the domains for which the given document is part of In 1.7, we made use of meta filters and filtered out percolators When we migrated to 7.2 with similar architecture, the performance degraded drastical… We can't use ParNewGC because we are on JDK12. We are experimenting using G1GC and ParallelOldGC. If the objects live for short time, why would I want to have a large useless old gen space? I'd give that space to the young gen instead right? Am I missing anything? Also other thing, the ES doc says the mini index for percolation is optimized for percolation purpose. My mappings have doc\_values as true [default], I'm guessing ES doesn't spend time on extracting doc\_values for that single document that gets indexed in the mini index [for percolation] --- _[View the full topic](https://discuss.elastic.co/t/slowness-in-percolator-7-2/200256)._