Making docid an int64 is a non-trivial undertaking, and this work needs to be compared against the use cases and how compelling they are.
That said, in the lifetime of most software projects a decision is made to break backward compatibility to move the project forward. When/if moving to int64 happens, it will be one of these moments. It is not a Bad Thing (necessarily). :-) And for use cases, if I am running a commercial JVM on a 64 core machine with 3TB of ram (we have these running), int64 for >2^32 documents in a single index should not be a problem... :-) glen On Fri, Aug 19, 2016 at 4:43 AM, Adrien Grand <jpou...@gmail.com> wrote: > Le ven. 19 août 2016 à 03:32, Trejkaz <trej...@trypticon.org> a écrit : > > > But hang on: > > * TopDocs#merge still returns a TopDocs. > > * TopDocs still uses an array of ScoreDoc. > > * ScoreDoc still uses an int doc ID. > > > > This is why ScoreDoc has a `shardId` so that you can know which index a > document comes from. > > I'm not saying we should not switch to long doc ids, but as outlined in > some other responses it would be a challenging change. >
