zihanx commented on issue #15905:
URL: https://github.com/apache/lucene/issues/15905#issuecomment-4185424929

   Thanks @gsmiller for the feedback and the benchmark! Really appreciate your 
help!
   To answer your questions:
   1. `ScoreDoc[] v.s. int[]`: For the doc-retriever use case, the API should 
be a generic class that takes `int[] globalDocIds` as input not `ScoreDoc[]`. 
@mikemccand originally described the retriever class as: 
   > A generic (reusable to open source) utility class to retrieve doc-values 
(DoubleValuesSource) for an int[] of global docids to return. API could be 
simple-ish, taking an open IndexReader, the int[] globalHits, and maybe 
DoubleValuesSource[]... Or, so other things (stored fields maybe) are 
supported, the API could be a bit more abstract, and caller passes in some sort 
of LeafVisitor factory lambda-a-jigger thingy 
   
   @mikemccand can you please help confirm this is the intended design? If so, 
even with Option 3, we'd still need two APIs (one for `ScoreDoc[]`, one for 
`int[]`), which is essentially Option 1 (or we could say even worse because 
option 1 would not introduce overhead).
   
   2. Overhead: Agree, the overhead might be noise compare to other work being 
done. 
   
   I think right now the problem we need to solve is what input type does the 
ordinal-tracking API need?
   Our current state only has one api: `partitionByLeaf(ScoreDoc[], leaves) → 
int[][]`, we still need to decide `ScoreDoc[]`/`int[]` input. 
   If we need `int[]` as the input for retriever class, I'm leaning towards 
option 1, which seems cleanest: two APIs with different input types and 
different return types based on use case.
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to