On Fri, May 22, 2015 at 10:02 AM, Matt Traynham <skitch...@gmail.com> wrote:
> Thanks for the clarification Adrien. If that's the case, is there such a > flag that can enable them by default for all fields (excluding non-analyzed > strings; using ~1.4.3 here)? > > Also, do you guys have more performance metrics on using Doc Values vs > FDC? I've seen the "10-25%" slower value thrown around, but I wanted to > know what that was tested with (CPU, mem, spinning vs. SSD, etc...) and > where gains may be had. > > in my debugging the current differences are usually the cost of a predictable branch (bounds check), coming from ByteBuffer.get(). For fielddata it uses simple java arrays, and today the java compiler can do optimizations to remove the checks more easily in that case. But IMO benchmarking here is usually not done correctly, it doesn't consider the impact of having such huge badly-compressed data in heap memory, e.g. impacts on GC and other problems people have. So i recommend doing a test with real data and real workloads :) -- Please update your bookmarks! We have moved to https://discuss.elastic.co/ --- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAD06sYSQ2U2y0D9ZOPMUDwywoXPYdAfq-6tDFsZOVKJ%3D0GatZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
