Valkey 7.3 KNN performance degradation on FLAT index

[vitusik]

Hi I'm using MemoryDB in AWS, with Valkey 7.3 as the underlying engine

I've got a vector index with 400k vectors - the vectors have a dimension of 1024

I'm running hybrid searches in my app, I've got 1 Tag field that I use to filter the results.

In my vec index, there is a dataset of 50k vec associated with a specific owner TAG, when I run a search query with that specific owner as a filter value, the query time spikes, for other owner values, the query time is very low, as expected.

output of a profile cmd

I ran 2 queries, one simple FT search with filter and one KNN search with a filter applied

Simple:
[[b'tag.count', 52768], [b'sync.time', 1], [b'query.time', 148263], [b'result.count', 52768], [b'result.time', 0]]
[[b'tag.count', 463], [b'sync.time', 1], [b'query.time', 4717], [b'result.count', 463], [b'result.time', 0]]

Hybrid:
[[b'tag.count', 0], [b'sync.time', 1], [b'query.time', 405819], [b'vector.count', 10], [b'vector.time', 405815], [b'result.count', 10], [b'result.time', 0]]
[[b'tag.count', 463], [b'sync.time', 1], [b'query.time', 697], [b'vector.count', 10], [b'vector.time', 695], [b'lowpass.count', 1], [b'result.count', 10], [b'result.time', 0]]

This is the output of my ft.info command

1. index_name
2. "Titan1024"
3. creation_timestamp
4. (integer) 1756014706597002
5. key_type
6. HASH
7. key_prefixes
8. 1. "Titan1024:"
9. fields
10. 1. 1. identifier
       2. text
       3. field_name
       4. text
       5. type
       6. TEXT
       7. option
    2. 1. identifier
       2. owner
       3. field_name
       4. owner
       5. type
       6. TAG
       7. option
    3. 1. identifier
       2. vector
       3. field_name
       4. vector
       5. type
       6. VECTOR
       7. option
       9. vector_params
    4. 1. algorithm
       2. FLAT
       3. data_type
       4. FLOAT32
       5. dimension
       6. (integer) 1024
       7. distance_metric
       8. COSINE
       9. initial_capacity
          10) (integer) 1000
          11) current_capacity
          12) (integer) 430804
          13) block_size
          14) (integer) 1024
11. space_usage
12. (integer) 210386304
13. fulltext_space_usage
14. (integer) 120326707
15. vector_space_usage
16. (integer) 90059597
17. num_docs
18. (integer) 428843
19. num_indexed_vectors
20. (integer) 428843
21. current_lag
22. (integer) 0
23. index_status
24. AVAILABLE
25. index_degradation_percentage
26. (integer) 0

I'd like to understand why the filter is not being applied before the KNN search, and causing a massive spike in query time,
Accuracy is very important for me, so I'm reluctant to move to HNSW index
Is there anything I can do, besides moving to HNSW index?

[allenss-amazon]

Can you provide the actual query string for the two different queries?

[murphyjacob4]

FYI - I believe AWS MemoryDB is not using the open source https://github.com/valkey-io/valkey-search/ implementation for KNN search. So you might have limited engagement here in the Valkey discussion board, since the details of their implementation is proprietary

[stockholmux]

Also, Valkey 7.3 isn't a release of Valkey. We went from 7.2.x to 8.0.0. Not sure what AWS equates this version to.