[GitHub] [lucene] jpountz commented on pull request #12064: Create new KnnByteVectorField and KnnVectorsReader#getByteVectorValues(String)

2023-01-08 Thread GitBox
jpountz commented on PR #12064: URL: https://github.com/apache/lucene/pull/12064#issuecomment-1374770702 I haven't thought much about it but I'd prefer to avoid increasing the number of vector types that are supported, 2 already feels like a lot. For instance, terms and points only understa

[GitHub] [lucene] rmuir commented on pull request #12064: Create new KnnByteVectorField and KnnVectorsReader#getByteVectorValues(String)

2023-01-08 Thread GitBox
rmuir commented on PR #12064: URL: https://github.com/apache/lucene/pull/12064#issuecomment-1374841078 Yes, lets design for today. Personally I will push back against new vector types/functions as long as performance is in its current state. -- This is an automated message from the Apache

[GitHub] [lucene] rmuir commented on pull request #12013: Clear thread local values on UTF8TaxonomyWriterCache.close()

2023-01-08 Thread GitBox
rmuir commented on PR #12013: URL: https://github.com/apache/lucene/pull/12013#issuecomment-1374852106 OK, crazy that having no cache at all could cause unnecessary amounts of flush/reopens. We want at least a small one. > I can close this PR and make that change if it makes sense. Or