feat(replays): Improve index page query performance

[cmanallen]

The /replays index page slows down when presented with large datasets. Given a large enough dataset some queries will OOM. By keeping fewer values in memory and making various performance optimizations to the query's structure we improve the performance of the query by 5x for our largest customers.

• Uses non-unique counting for the count_errors field.
  • Breaking change from previous design.
  • Reduces memory usage.
• Removes urls_sorted dependency for count_urls and replaces with simple count.
  • Improves activity performance.
  • Reduces memory usage.
• For ALL grouped scalar fields we have replaced groupUniqArray with groupArray(1). This is faster (no unique requirements) and more memory efficient (we only ever have one value in memory).
• project_id is no longer a grouped scalar value. It is included in the GROUP BY clause.
• Fixed an error where trace and error ids were filtering against the column rather than the aggregation.

[JoshFerge]

@cmanallen yeah i definitely think we can optimize project_id and user too. for project_id, i don't think we need to aggregate them all before selecting the first one. the project_id is guaranteed to be the same for each replay segment. we can likely simply group by project_id, or use a max_size of 1 and groupArray.

for user_id, we can run a quick query to verify but it should be the same on all segments, so the strategy w/ max_size and groupArray should work there.

[cmanallen]

we can likely simply group by project_id

@JoshFerge Wow, yes. Very astute observation. 33% speed-up on large datasets.

[cmanallen]

for user_id, we can run a quick query to verify but it should be the same on all segments, so the strategy w/ max_size and groupArray should work there.

Added. 25% speed-up.

[JoshFerge]

🚀