it is good, that you asked this question, because it made me realize,
that there is some room for improvement for our own application :-)
Thanks
Michael
Am 12.02.24 um 11:35 schrieb Uthra:
@Gautam - Thanks for your response. Our leaf reader API approach is the one you
mentioned. I wanted to
Hi,
reading information from the inverted index (and also vectors) is always
slow, because the data is not stored "as is" for easy reconsumption. To
allow easy reindexing, there input data must be serialized to a "stored"
field in parallel to the indexed value.
Elasticearch is using the appr
@Gautam - Thanks for your response. Our leaf reader API approach is the one you
mentioned. I wanted to make sure the best way to read vectors for our case.
@Michael - Yes Michael that’s the case here.
Regards,
Uthra
> On 12-Feb-2024, at 1:23 PM, Michael Wechner wrote:
>
> thanks for explainig
thanks for explainig, Uthra!
IIUC the text / data for which the vector was originally generated was
not changed, only some other data (e.g. meta data) which is also part of
the Lucene document, right?
So, if you want to update the other data within the Lucene document, you
first retrieve the L
Hi,
> Using LeafReader’s API to read vector. Here the Random accessing of
documents is very slow.
Is it possible that you are creating a new VectorValues instance for every
doc whose value you want to look up?
Ideally, you should sort your docids and then advance to them one by one,
or call nextD
Hi Michael,
The use case is to handle index updates along with its vector field
without resending the vector in change data every time. The change data will
consist of only “updated_field(s):value(s)” wherein I will read the vector
value from Index to update the document.
Thanks,
Uthra
Can you describe your use case in more detail (beyond having to read the
vectors)?
Thanks
Michael
Am 09.02.24 um 12:28 schrieb Uthra:
Hi,
Our project uses Lucene 9_7_0 and we have a requirement of frequent
vector read operation from the Index for a set of documents. We tried two
app
