Review count() implementation - consider FT.AGGREGATE

[abrookins]

Summary

The current FindQuery.count() implementation uses FT.SEARCH with LIMIT 0 0 and nocontent=True:

async def count(self):
    query = self.copy(offset=0, limit=0, nocontent=True)
    result = await query.execute(exhaust_results=True, return_raw_result=True)
    return result[0]

This works, but FT.AGGREGATE with a count reducer may be a better approach.

Why FT.AGGREGATE might be better

1. Purpose-built for aggregations - FT.AGGREGATE is designed for operations like counting, grouping, etc.
2. More flexible - Could support count() with grouping (e.g., count by category)
3. Potentially more efficient - Aggregation pipeline is optimized for this use case

Example with FT.AGGREGATE

FT.AGGREGATE idx * GROUPBY 0 REDUCE COUNT 0 AS total

This returns just the count without any document data.

Tasks

• Benchmark current FT.SEARCH LIMIT 0 0 vs FT.AGGREGATE for count
• Evaluate if FT.AGGREGATE provides any performance benefits
• Consider adding grouped count support (e.g., Model.find().count(group_by="category"))

[abrookins]

Good investigation. Worth benchmarking both approaches.

Current approach:

# FT.SEARCH with LIMIT 0 0
result = await FT.SEARCH(idx, query, LIMIT, 0, 0, NOCONTENT)
return result[0]  # Returns count

Proposed approach:

# FT.AGGREGATE with COUNT reducer
result = await FT.AGGREGATE(idx, query, GROUPBY, 0, REDUCE, COUNT, 0)

FT.AGGREGATE benefits:

1. Purpose-built for aggregations
2. Foundation for grouped counts: Model.find().count(group_by="category")
3. Potentially more efficient for complex queries

Related: PR #313 implemented count() using FT.AGGREGATE with matched_terms() before being closed for staleness. This aligns with broader aggregation support tracked in #258.

Tasks to evaluate:

• Benchmark comparison of both approaches
• Prototype grouped count feature
• Consider adding aggregate() method to FindQuery

Keeping open as enhancement.