Details
-
Bug
-
Resolution: Fixed
-
Major
-
5.5.0
-
CentOS 7.4
E5-2680 v3 (48 vCPU)
-
Untriaged
-
Centos 64-bit
-
No
Description
As discussed, I am creating a ticket for further investigation of why some aggregation queries are slower than expected.
Setup:
- 4 KV nodes, 1 query node, 1 index node
- 1 bucket
- 100M documents (denormalized store_sales from TPC-DS)
- MOI indexes
- Single client thread (no concurrency)
Queries and indexes:
https://docs.google.com/document/d/1C0mOKGn-d9HKV6SCaHGlSm1FkfoJQ23Stmr5lmBAA3M/edit#heading=h.czsz4i2s2rvl
Results for build 5.5.0-1863:
query | w/o pushdown | w/ pushdown |
---|---|---|
AG1 | 12s | 10s |
AG2 | index scan timed out | index scan timed out |
AG3 | 150-200 ms | 200-250 ms |
AG4 | ||
AG5 | 3 s | 3 s |
AG6 | 30 s | 200 ms |
AG7 | < 50ms | < 50ms |
AG8 | 500 ms | 500 ms |
AG9 | 18 s | 18 s |
AG10 | < 50ms | < 50ms |
Attachments
Issue Links
- relates to
-
MB-28698 improve scan stat gathering
- Open
-
MB-28915 optimize collatejson DecodeFloat
- Open
-
MB-28598 Perf Improvement: Optimize decode occurring across source and decode stages in scan pipeline
- Closed
-
MB-29010 Consider optimizing expression Evaluate/annotatedValue SetCover
- Closed
-
MB-28599 Optimize ExplodeArray further to avoid garbage allocation
- Closed