I dont have any measured data, but here are my thoughts. I think overall memory usage would be close to the same. Speed will be slower in general, because if search speed is approx log(n) then 10 * log(n/10) > log(n), and also if merging results you have overhead in the merge step and also if fetching results beyond the first page since you would generally need page_size * page_number from each core. Of course if you search many cores in parallel over many CPU cores you would mitigate that overhead. There are other considerations such as caching - for example if you are adding new documents on one core only, the other cores get to keep there filter caches, etc. in RAM much longer than if you are always committing to one single large core. And then of course if you have some client logic to pick a sub-set of cores based on some query data (such as only searching newer cores, etc.) then you could end up with faster search over many cores.
2011/12/15 Yury Kats <yuryk...@yahoo.com>: > Does anybody have an idea, or better yet, measured data, > to see what the overhead of a core is, both in memory and speed? > > For example, what would be the difference between having 1 core > with 100M documents versus having 10 cores with 10M documents?
