A slow search query doesn't 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂 𝘄𝗵𝗮𝘁 𝘁𝗼 𝗼𝗽𝘁𝗶𝗺𝗶𝘇𝗲. The latency could be co...

Weaviate AI Database on X: "A slow search query doesn't 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂 𝘄𝗵𝗮𝘁 𝘁𝗼 𝗼𝗽𝘁𝗶𝗺𝗶𝘇𝗲. The latency could be coming from filter evaluation, HNSW traversal, compressed-vector rescoring, BM25 scoring, or reading final objects from disk. Each points to a completely different fix. Weaviate now has 𝗽𝗲𝗿-𝗾𝘂𝗲𝗿𝘆 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 to make that breakdown concrete. Set one opt-in flag on a search and the timing profile comes back directly on 'response.query_profile'. The coordinating node collects profiles from every participating shard and node, so you get a cluster-wide view in one response. No restart, latency threshold, waiting for the query to be slow again, or manually stitching together logs across nodes. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗲 𝗽𝗿𝗼𝗳𝗶𝗹𝗲 𝗰𝗮𝗻 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂: - objects_took is high: object hydration is disk-bound. Check page-cache misses, result limits, or large payloads. - filters_build_allow_list_took is high: the where filter is expensive. filters_ids_matched helps separate a broad cardinality problem from disk reads. - vector_search_took is high: inspect HNSW layer timings. Layer 0 normally dominates, with ef, dimensionality, and filter strategy as the relevant tuning levers. - knn_search_rescore_took is high: compressed candidates are expensive to rescore, potentially because full-precision vectors are being read from disk. For example, one profile might show: • 48.2ms total • 36.8ms reading objects • 8.4ms in vector search • 2.1ms building the filter allow-list The vector index isn't the bottleneck. Tuning HNSW would be a guess. The profile points toward storage, page cache, result limit, or payload size instead. Slow query logging is still useful for passively catching regressions across a fleet. But when one specific query is slow, profiling gives you the actual stage to investigate. Read the full blog by @ByronVoorbach: https://t.co/ygpB4Eb2l8 Docs: https://t.co/70FsH62A3G" / X

Weaviate AI Database

@weaviate_io

A slow search query doesn't 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂 𝘄𝗵𝗮𝘁 𝘁𝗼 𝗼𝗽𝘁𝗶𝗺𝗶𝘇𝗲. The latency could be coming from filter evaluation, HNSW traversal, compressed-vector rescoring, BM25 scoring, or reading final objects from disk. Each points to a completely different fix. Weaviate now has 𝗽𝗲𝗿-𝗾𝘂𝗲𝗿𝘆 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 to make that breakdown concrete. Set one opt-in flag on a search and the timing profile comes back directly on 'response.query_profile'. The coordinating node collects profiles from every participating shard and node, so you get a cluster-wide view in one response. No restart, latency threshold, waiting for the query to be slow again, or manually stitching together logs across nodes. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗲 𝗽𝗿𝗼𝗳𝗶𝗹𝗲 𝗰𝗮𝗻 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂: - objects_took is high: object hydration is disk-bound. Check page-cache misses, result limits, or large payloads. - filters_build_allow_list_took is high: the where filter is expensive. filters_ids_matched helps separate a broad cardinality problem from disk reads. - vector_search_took is high: inspect HNSW layer timings. Layer 0 normally dominates, with ef, dimensionality, and filter strategy as the relevant tuning levers. - knn_search_rescore_took is high: compressed candidates are expensive to rescore, potentially because full-precision vectors are being read from disk. For example, one profile might show: • 48.2ms total • 36.8ms reading objects • 8.4ms in vector search • 2.1ms building the filter allow-list The vector index isn't the bottleneck. Tuning HNSW would be a guess. The profile points toward storage, page cache, result limit, or payload size instead. Slow query logging is still useful for passively catching regressions across a fleet. But when one specific query is slow, profiling gives you the actual stage to investigate. Read the full blog by

@

ByronVoorbach

:

weaviate.io/blog/query-pro…

Docs:

docs.weaviate.io/weaviate/searc…

4:00 PM · Jul 21, 2026

653

Views

1

4

9