In scenarios where search requests include multiple product-level filters using the efq parameter, customers may observe increased response latency from search APIs.

This typically occurs when a large number of product IDs are passed in a single request, for example:
 

&efq=pid:"<pid1>" OR "<pid2>" OR "<pid3>" OR ... OR "<pid20>"

As the number of conditions grows, the performance degradation becomes more noticeable, particularly in high-traffic or large-catalogue environments.
 

Root Cause Analysis

The performance overhead stems from how the Bloomreach Search frontend processes the efq parameter.

• The efq (extended filter query) is parsed and translated into underlying Apache Solr query parameters.
• During this transformation, the system relies on regex-based parsing and pattern matching to interpret and construct the final query.
• Regex operations introduce additional computational complexity, which increases with:
  • The number of product IDs
  • The size of the dataset being queried
• As a result, queries with large OR-based conditions in efq can lead to slower execution times and higher latency.

Recommendation

Why Use “Exclude” Instead?

• Designed specifically for real-time merchandising use cases
• Avoids regex-heavy query transformations
• More efficient execution at scale
• Reduces query complexity and improves response time

Suggested Approach

Instead of:

&efq=pid:"<pid1>" OR "<pid2>" OR "<pid3>" ...

Use:

exclude=pid:<pid1>,<pid2>,<pid3>,...

Summary

While efq provides flexibility for advanced filtering, it is not optimised for large-scale exclusion scenarios. For better performance and scalability, the “exclude” operation offers a more efficient and purpose-built alternative.