Unfortunately, we have about 8 different fields that could serve as aggregation key, and a lot of potential combinations between these fields. Thus, pre-computing all these combinations doesn't seem to be a viable solution.
On Friday, January 31, 2014 7:52:40 AM UTC-8, Binh Ly wrote: > > Maxime, your bottleneck is likely in the script part. It has to > dynamically compute that per doc just like in sql. However, if you can > precompute that at index time (for example, introduce a field that contains > the value of date-hour-id, you should be able to improve that aggregation > time significantly. I did a quick test in 1.0 RC1 with an index of about > 100K docs, and if I precompute that term field (and eliminate the script > part), it is at least 10x faster than the script version. YMMV. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/134a71d9-7683-4804-9ae9-449d40580b35%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
