bq: What do you mean by 'be in the JVM'? I wasn't sure if a more efficient searching structure would be built in the JVM or not, building an inverted structure out of docValues there. But you're saying not, it's a linear scan of the uninverted structure out in the OS's memory.
It would have been quite ironic if we started seeing a message like "inverting docValues field for searching" in the logs. Symmetrical to the background for docValues I'll admit... ;) Thanks for the confirmation. That leaves whether this is reasonable behavior or not. It feels like a documentation issue, something like 'While searching on fields having docValues="true", indexed="false" is possible, it is orders of magnitude slower than searching on fields with indexed="true". We _strongly_ recommend that any field that is used for searching be configured with indexed="true" ' That's assuming that just dis-allowing searching on dv=true, indexed=false fields is not an option. WDYT? Erick On Mon, Aug 28, 2017 at 12:55 PM, Adrien Grand <[email protected]> wrote: > Indeed this will be a linear scan if it is not intersected with a selective > query, which is quite trappy. > > What do you mean by 'be in the JVM'? > > Le lun. 28 août 2017 à 21:49, Erick Erickson <[email protected]> a > écrit : >> >> You can search on fields with DV=true and indexed=false. But IIUC this >> is a "table scan". Does it really make sense to support this? >> >> NOTE: Haven't checked the code, but even if we build an efficient >> structure, it would be in the JVM, correct? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
