PathFinder: Efficiently Supporting Conjunctions and Disjunctions
for Filtered Approximate Nearest Neighbor Search

Abstract.

Filtered approximate nearest neighbor search (ANNS) restricts the search to data objects whose attributes satisfy a given filter and retrieves the top-$K$ objects that are most semantically similar to the query object. Many graph-based ANNS indexes are proposed to enable efficient filtered ANNS but remain limited in applicability or performance: indexes optimized for a specific attribute achieve high efficiency for filters on that attribute but fail to support complex filters with arbitrary conjunctions and disjunctions over multiple attributes. Inspired by the design of relational databases, this paper presents PathFinder, a new indexing framework that allows users to selectively create ANNS indexes optimized for filters on specific attributes and employs a cost-based optimizer to efficiently utilize them for processing complex filters. PathFinder includes three novel techniques: 1) a new optimization metric that captures the tradeoff between query execution time and accuracy, 2) a two-phase optimization for handling filters with conjunctions and disjunctions, and 3) an index borrowing optimization that uses an attribute-specific index to process filters on another attribute. Experiments on four real-world datasets show that PathFinder outperforms the best baseline by up to 9.8$\times$ in query throughput at recall 0.95.

PVLDB Reference Format:
PathFinder: Efficiently Supporting Conjunctions and Disjunctions for Filtered Approximate Nearest Neighbor Search. PVLDB, 14(1): XXX-XXX, 2020.
doi:XX.XX/XXX.XX

PVLDB Artifact Availability:
The source code, data, and/or other artifacts have been made available at %leave␣empty␣if␣no␣availability␣url␣should␣be␣set%****␣main.tex␣Line␣75␣****URL_TO_YOUR_ARTIFACTS.

1. Introduction

Vector databases are the foundational infrastructure for semantic search and have been adopted to support a broad range of information systems, such as retrieval-augmented generation systems for large language models (Jiang et al., 2023; Guu et al., 2020; Jiang et al., 2025a; Trivedi et al., 2023), recommendation systems (Wei et al., 2020; Rajput et al., 2023), search engines (Luc, 2025; Ope, 2025; Ela, 2025), and knowledge bases (Mohoney et al., 2023; Edge et al., 2024; Ilyas et al., 2022). Vector databases support semantic search by encoding each data object, such as a document or an image, into a high-dimensional vector, and quickly but approximately finding the top-$K$ data objects that are most semantically similar to a query object (i.e., a similarity query) based on vector distances (mil, 2025; Wang et al., 2021; chr, 2025; wea, 2025; lan, 2025; Wei et al., 2020; qdr, 2025; Chen et al., 2024; Fu et al., 2019; Malkov and Yashunin, 2020; Jayaram Subramanya et al., 2019), known as approximate nearest neighbor search (ANNS). When processing a similarity query with a filter on the attributes of the data objects (e.g., searching for the papers in the “DB” field and published after 2025), ANNS restricts the search to the subset of data objects passing the filter, known as filtered ANNS.

Efficiently and accurately supporting filtered ANNS remains challenging, as the performance of existing ANNS indexes degrades significantly under complex filters. Graph-based indexes, for example, are widely adopted to support ANNS due to their strong tradeoff between query execution time and accuracy (Jayaram Subramanya et al., 2019; Malkov and Yashunin, 2020; Fu et al., 2019; Malkov et al., 2014; Ait Aomar et al., 2025). The core of graph-based indexes is the proximity graph, which represents data objects as vertices and connects each vertex to a bounded number of nearby vertices based on vector distances (Jayaram Subramanya et al., 2019; Malkov and Yashunin, 2020; Malkov et al., 2014). However, the filter associated with a similarity query can induce a sparse or even disconnected subgraph (Singh et al., 2021), significantly degrading search efficiency and accuracy.

Figure 1. A tree-based graph index built on a numeric attribute. The attribute range is recursively partitioned, and for each tree node, a proximity graph is built over the data objects whose attribute values fall within the node’s range.

Recent studies have proposed new graph-based indexes to address the challenge of sparse graphs in filtered ANNS. However, these approaches remain limited in their applicability or performance. A line of research focuses on indexes optimized for filters on a single attribute of a particular data type (Zuo et al., 2024; Xu et al., 2024; Wang et al., 2023; Gollapudi et al., 2023; Engels et al., 2024; Gupta et al., 2023; Liang et al., 2025; Ait Aomar et al., 2025; Cai et al., 2024), referred to as attribute-specific indexes. Their goal is to construct sufficiently dense proximity graphs to process filters on the attribute they are optimized for. As a result, when processing filters on the attributes they are optimized for, they offer substantial performance advantages over graph-based indexes that support general filters (Patel et al., 2024; Malkov and Yashunin, 2020; Jayaram Subramanya et al., 2019). However, it remains an open challenge to effectively utilize attribute-specific indexes to support filters with arbitrary conjunctions and disjunctions.

Our approach. This paper presents PathFinder, a novel graph-based indexing framework for efficient filtered ANNS that supports general filters with conjunctions and disjunctions. The design of PathFinder is guided by a key principle drawn from the practical considerations of relational databases: since it is prohibitively expensive to build indexes for all possible attribute combinations, DBMSs allow administrators to create indexes on selected attributes and rely on a cost-based optimizer to leverage these indexes for efficiently processing general multi-attribute filters. Following this insight, PathFinder allows the vector database administrators to create attribute-specific ANNS indexes on selected attributes and designs a cost-based optimizer to utilize the available indexes to efficiently process similarity queries with complex filters.

Specifically, PathFinder models data objects as a database relation, where the columns represent the embedding vector and associated attributes, which may be numeric or categorical. It supports tree-based and hash-based graph indexes optimized for individual attributes. Tree-based graph indexes have shown state-of-the-art search performance for single-attribute range filters (Engels et al., 2024; Jiang et al., 2025b; Xu et al., 2024; Wang et al., 2025) and support efficient updates (Jiang et al., 2025b; Wang et al., 2025). We adopt a multi-way tree structure (Jiang et al., 2025b) and include a new cost-based method for efficiently using this index structure to support both single-attribute and multi-attribute filters. Figure 1 shows an example of this tree-based graph index. It recursively partitions the value range of an attribute, like a B⁺-tree, and builds a proximity graph for each node over the data objects whose corresponding attribute values fall into this node’s range. Processing a range predicate involves selecting one or more proximity graphs from the tree. For instance, to process the range predicate $6\leq value\leq 8$ using the index in Figure 1, the system may choose to search the proximity graph corresponding to the node $(4,8]$, as this graph contains the highest proportion of nodes that satisfy the filter. As a complement to tree-based indexes, we use hash-based indexes to support categorical data and point predicates (e.g., topic = “DB” or topic in [“DB”, “CV”]). It builds a proximity graph for all data objects with the same categorical value.

Technical challenges. PathFinder adopts a query optimizer that selects a subset of proximity graphs from attribute-specific indexes to efficiently process a similarity query with a filter (i.e., a filtered similarity query). Building such an optimizer requires overcoming two key challenges. First, we need an optimization metric that captures the tradeoff between query execution time and accuracy for filtered ANNS. A higher value of this metric should indicate a better tradeoff between the two factors. Intuitively, we might prefer dense proximity graphs (i.e., the ones containing more nodes satisfying the predicate). However, such a metric would favor many small proximity graphs, which in turn increases execution time. Consider the tree-based index in Figure 1. For a predicate $1\leq value\leq 8$, prioritizing dense graphs will choose $(-\infty,4]$ and $(4,8]$ although the graph for $(-\infty,8]$ might be a better choice. This motivates the need for a new metric that balances the density and the number of proximity graphs involved. Second, executing a similarity query is fast, typically completing in sub-milliseconds to a few milliseconds, which leaves a small optimization budget. Meanwhile, the optimizer must consider many combinations of proximity graphs from attribute-specific indexes for a complex filter predicate. It is challenging to select the subset of proximity graphs that can efficiently process the query within the tight optimization time budget.

PathFinder optimizer. PathFinder addresses these challenges with two key techniques: (1) a new metric that can quantify the efficiency of executing a filtered similarity query on a set of proximity graphs and can be quickly estimated to determine the relative ordering without computing exact values; and (2) a two-phase optimization process that efficiently selects the proximity graphs for answering a filtered similarity query.

Specifically, we design a new metric, search utility, that balances the graph density for a filter against the number of proximity graphs. This metric favors subsets of graphs that achieve a higher overall density while reducing the total number of graphs used. Moreover, since the optimizer only needs to compare the relative efficiency of different subsets of graphs, the search utility is carefully formulated so that our estimation method only needs to compute the components that determine their relative ordering, without performing costly cardinality estimation (i.e., estimating the number of nodes in a graph passing a filter). To process a filtered similarity query, PathFinder converts the filter predicate into disjunctive normal form (DNF), where conjunctive clauses are connected by disjunctions, and processes conjunctions and disjunctions sequentially. For each conjunctive clause, PathFinder efficiently identifies up to two promising subsets of proximity graphs per attribute-specific index and selects the subset with the highest search utility across all indexes. For disjunctions, PathFinder groups the proximity graphs selected for all conjunctive clauses by index and removes duplicates. Within each group, PathFinder adopts a novel algorithm that exploits the tree-based index structure to identify common ancestor proximity graphs that can subsume and replace the graphs in the group, thereby further improving the search utility.

Optimization: index borrowing. Users may issue filter predicates on attributes for which no attribute-specific indexes are available. While PathFinder can still process such queries using the proximity graph that covers all data objects in the relation (e.g., the graph for the root node in Figure 1), its performance will degrade when handling complex filters. To address this, PathFinder introduces an index-borrowing optimization that leverages an index built on one attribute to process a filter on another. The key insight is that when two attributes are correlated, we can synthesize a new predicate on one attribute for which the index is available based on the input predicate. PathFinder then uses this synthesized predicate to select proximity graphs from the corresponding index that can more efficiently process the filtered similarity query.

Evaluation. To evaluate the effectiveness of PathFinder, we compare PathFinder with five baselines that support multi-attribute filters on numeric and categorical data. We use four datasets and generate query workloads that include filters with conjunctions and disjunctions. Our experiments show that PathFinder has up to 9.8$\times$ higher throughput at recall 0.95 than the best baseline.

Research vision. PathFinder opens a new direction for supporting filtered ANNS in vector databases by drawing on successful practice from relational databases: adopting a cost-based optimizer to best utilize available attribute-specific indexes to provide efficient filtered ANNS. This framework can potentially support new attribute-specific indexes or new data types (e.g., label data) and predicates (e.g., regex-based string matching), which is left for future work. Moreover, it introduces new research opportunities, such as index compression for reducing memory consumption and automatic index recommendation (Ding et al., 2019) for filtered ANNS.

2. Background and Problem Statement

Vector databases and ANNS. Vector databases support approximate nearest neighbor search (ANNS) by converting data objects (e.g., images or documents) into high-dimensional vectors and approximately retrieving the $K$ most semantically similar objects for a given query (i.e., similarity queries) based on the distances between the vector of the query and the vectors stored in the database (mil, 2025; Wang et al., 2021; chr, 2025; wea, 2025; lan, 2025; Wei et al., 2020; qdr, 2025; Chen et al., 2024). The accuracy is measured by recall: $recall\text{@}K=\frac{|R\cap R^{\prime}|}{K}$, where $R$ is top-$K$ nearest neighbors returned by ANNS and $R^{\prime}$ is the ground truth top-$K$ result.

Graph-based indexes. Vector databases rely on indexes to perform ANNS. Graph indexes, such as HNSW (Malkov and Yashunin, 2020) and Vamana (Jayaram Subramanya et al., 2019), have been widely adopted due to their strong performance in balancing search time and accuracy, particularly in high-dimensional vector spaces. The core of graph indexes is using proximity graphs to guide similarity search. In a proximity graph, each data object is represented as a vertex and connects to a bounded number of nearby vertices via directed edges based on the vector distances.

Finding the top-$K$ nearest neighbors adopts best-first search (Malkov et al., 2014; Malkov and Yashunin, 2020; Jayaram Subramanya et al., 2019; Fu et al., 2019). The algorithm maintains a bounded size of search queue that stores candidate vertices for answering the similarity query. Starting from one or more entry points, the unexpanded vertex that is closest to the query vector in the queue is expanded by adding its neighbors to the queue, which only keeps a fixed number of vertices closest to the query vector. The search continues until convergence, typically when no newly expanded neighbors are closer than the farthest vertex in the queue. The size of the queue is configurable, allowing for a tradeoff between search time and accuracy.

Figure 2 shows an example of best-first search. The search begins at vertex A, with the queue initially containing A. After expanding A, its vertices B and D are added to the queue. The algorithm then picks the vertex with the smallest distance to the query vector (i.e., B in this example), expands it, and updates the queue with its unvisited neighbor, C. Since the queue has a maximum size of 3, the farthest vertex to the query in the queue, D, is removed. Finally, the search terminates because C’s unvisited neighbor E has a larger distance to q than the farthest node currently in the queue (i.e., C).

HNSW (Malkov and Yashunin, 2020) uses a hierarchy of proximity graphs to quickly locate an entry point in the bottom layer that is likely near the region that includes the nearest neighbors to the query vector. The Vamana graph (Jayaram Subramanya et al., 2019) simplifies the design by using a single proximity graph without hierarchy and introduces long-range edges to accelerate convergence toward the region closest to the query vector. PathFinder uses the Vamana graph as its proximity graph.

Filtered ANNS. A similarity query often includes a filter on data object attributes, such as price, topic, or timestamp. The filter restricts the ANNS search to only those objects that satisfy the condition, a problem known as filtered ANNS.

The primary challenge for efficiently supporting filtered ANNS is that the filter induces a sparse or even disconnected proximity graph. Three basic strategies are adopted for supporting filtered ANNS. The pre-filtering strategy skips the ANNS index by comparing the query vector with all vectors that satisfy the filter; it is only effective when the filter selectivity is extremely low (Patel et al., 2024; Wei et al., 2020). The in-filtering strategy applies filters during the similarity search on the ANNS index (e.g., a graph index). The post-filtering strategy first searches the index and then applies the filter to the retrieved results. If fewer than $K$ objects satisfy the filter, the search is retried with a longer search queue to find additional valid candidates.

Beyond the basic strategies, recent studies have proposed new graph indexes to address the challenge of sparse graphs  (Zuo et al., 2024; Patel et al., 2024; Xu et al., 2024; Engels et al., 2024; Cai et al., 2024; Jiang et al., 2025b; Liang et al., 2025; Li et al., 2025; Mohoney et al., 2023; Ait Aomar et al., 2025; Wang et al., 2025). They materialize additional edges, construct filter-specific proximity graphs, or visit nodes that do not pass the filter (i.e., out-of-range nodes) to ensure that the search is performed over a sufficiently dense graph. However, existing methods remain limited in applicability or performance. One line of work builds graph indexes tailored to a single attribute of a particular data type (Zuo et al., 2024; Engels et al., 2024; Liang et al., 2025; Xu et al., 2024; Jiang et al., 2025b; Cai et al., 2024; Ait Aomar et al., 2025; Wang et al., 2025; Gupta et al., 2023; Wang et al., 2023), such as constructing proximity graphs for different subranges of a numeric attribute. These approaches achieve significantly higher performance than general indexes that support arbitrary filters (Patel et al., 2024; Malkov and Yashunin, 2020; Jayaram Subramanya et al., 2019), but cannot efficiently support multi-attribute filters with arbitrary conjunctions and disjunctions. Other studies support complex filters but require that the filter workload is known (Li et al., 2025; Mohoney et al., 2023).

Figure 2. An example illustrating best-first search on a proximity graph for a graph index

Problem statement. We aim to build an indexing framework, PathFinder, which leverages high-performance attribute-specific indexes (Xu et al., 2024; Jiang et al., 2025b; Engels et al., 2024) to support multi-attribute filters with conjunctions and disjunctions. This framework is similar to the access path selection framework in relational databases which best uses the indexes built on specific attributes to process multi-attribute filters.

PathFinder uses a relation $T(pk,a_{1},a_{2},\dots,a_{k},\mathsf{object},\mathsf{vector})$ to represent data objects, each of which is modeled as a tuple including a primary key $pk$, $k$ attributes $a_{1},a_{2},\dots,a_{k}$, a data object, and the vector embedding for the object. We assume a collection of attribute-specific graph-based indexes $I=\{I_{a_{i}}\mid a_{i}\in A_{I}\}$, where $A_{I}\subseteq\{a_{1},a_{2},\dots,a_{k}\}$ is the subset of attributes for which indexes are built, and each $I_{a_{i}}$ is an index on attribute $a_{i}$.

The research problem PathFinder addresses is how to utilize the index collection $I$ to answer filtered similarity queries such that the system has the best tradeoff between query throughput and recall.

Figure 3. The workflow of PathFinder for processing an example query

3. System Designs

We now present the designs of PathFinder. We first give an overview of the framework and then describe the specific techniques in detail.

3.1. PathFinder Overview

PathFinder represents a set of data objects along with their attributes and vectors as a relation $T(pk,a_{1},a_{2},\dots,a_{k},\mathsf{object},\mathsf{vector})$, and assumes DBMS administrators have chosen to create a collection of graph indexes $I$ for a subset of attributes, with each graph index $I_{a_{i}}$ corresponding to the attribute $a_{i}$. Each attribute can be either a numeric value or a categorical value represented as a string.

Supported indexes and predicates. PathFinder currently supports tree-based graph indexes (Jiang et al., 2025b) for range and point filters and hash-based graph indexes for point filters only. Specifically, the tree-based graph index adopts a multi-way tree structure (Jiang et al., 2025b) that recursively partitions the value range of an attribute, similar to a B⁺-tree, and builds a proximity graph for each tree node. Figure 1 illustrates an example, where the value range of a non-leaf node is partitioned into two. A hash-based graph index supports categorical attributes without ordering. It employs a hash table to map each categorical value to the partition of tuples with that value, and then builds a proximity graph for each partition. For example, building a hash-based graph index for the “topic” attribute of a set of research papers will partition the papers by topic (e.g., “DB” vs. “CV”) and construct a separate proximity graph for each partition. We choose the Vamana graph (Jayaram Subramanya et al., 2019) as the proximity graph in PathFinder.

Figure 3 shows an example of a tree-based index and a hash-based index built on attributes $a_{1}$ and $a_{2}$, respectively. PathFinder builds a proximity graph for all tuples by default (e.g., $g_{r}$ in Figure 3), which also serves as the root node for both the tree-based and hash-based indexes. That is, $g_{r}$ is the parent node of the proximity graphs $g_{1}$ and $g_{2}$ for the tree-based index and is the parent node of $g_{7}$-$g_{9}$ for the hash-based index. Therefore, the hash-based index trivially adopts a two-layer tree structure.

A tree-based graph index for an attribute $a_{i}$ supports a variety of range predicates, such as $a_{i}\geq c$, $a_{i}\leq c$, $a_{i}=c$, $a_{i}<c$, and $a_{i}>c$, where $c$ is a literal. A hash-based graph index supports categorical predicates, including equality ($a_{i}=c$) and membership ($a_{i}\text{ IN }S$ for a set of values $S$). PathFinder supports Boolean combinations of these atomic predicates through conjunctions and disjunctions.

PathFinder optimizer. Given a filtered similarity query and a set of attribute-specific indexes that comprise proximity graphs, PathFinder adopts a cost-based approach that selects a subset of proximity graphs to best process this query. To guide the optimization, we define a novel optimization metric, search utility, which jointly balances recall and search time to favor subsets of graphs that achieve higher overall density with respect to the filter predicate while reducing the number of graphs to search. Moreover, the search utility can be quickly estimated to decide the relative orderings without computing the exact values. We present the definition of search utility and the estimation method in Section 3.2

PathFinder then includes a two-phase optimization mechanism that quickly finds an execution plan for processing the filtered similarity query while maximizing the search utility. Specifically, the execution plan is represented as the subsets of proximity graphs selected from each available index $I_{a_{i}}$, referred to as a graph search plan. PathFinder then searches each proximity graph in this plan and combines their results to return the top-K data objects to users.

Figure 3 shows the workflow for processing an example filtered similarity query. PathFinder processes the filter predicate $p$ in disjunctive normal form (DNF), which expresses $p$ as a disjunction of conjunctive clauses: $p=C_{1}\lor C_{2}\lor\cdots\lor C_{m}$, where each clause $C_{i}$ is a conjunction of atomic predicates on individual attributes.

For a conjunctive clause $C_{i}$, the optimizer considers all indexes involved in $C_{i}$, finds up to two promising graph search plans for each index, and chooses the one with the highest search utility across all indexes. For the example in Figure 3, we have $C_{1}=p_{1}\land p_{2}$ and $C_{2}=p_{3}\land p_{4}$. PathFinder selects $\{g_{3}\}$ and $\{g_{4}\}$ for $C_{1}$ and $C_{2}$, respectively. To process disjunctions, a naïve approach is to execute the graph search plan for each conjunctive clause independently. PathFinder improves upon this by combining the graph search plans for more efficient execution. Specifically, PathFinder merges and deduplicates the plans, groups their proximity graphs by index, and leverages the index hierarchy to identify ancestor graphs that can replace descendant graphs to reduce redundancy and improve execution efficiency. For example, in Figure 3, given $\{g_{3},g_{4}\}$ as the output from the previous phase, PathFinder may select $\{g_{1}\}$ to replace $\{g_{3},g_{4}\}$ because $g_{1}$ covers the value ranges of $g_{3}$ and $g_{4}$ and may be more efficient to search (depending their relative search utility values). We describe processing conjunctions and disjunctions in Sections 3.3–3.4. We include an optimization in Section 3.5, which leverages existing indexes to process predicates on attributes that lack dedicated indexes.

3.2. Search Utility

PathFinder selects a subset of proximity graphs from the available indexes to efficiently answer a filtered similarity query. Intuitively, proximity graphs that have a higher fraction of nodes passing the filter (i.e., dense graphs) are preferred, as searching them improves recall and reduces search time. However, using too many dense graphs, such as all leaf nodes covered by a predicate in a tree-based index, adds a linear factor to the otherwise logarithmic graph search complexity, increasing overall search time. PathFinder therefore introduces an optimization metric that balances the two factors.

Designing such a metric presents a key challenge: minimizing the time cost of evaluating its value. Executing a similarity query is fast, typically within sub-milliseconds to a few milliseconds, leaving a tight time budget for the optimizer. Estimating graph density (i.e., estimating the fraction of graph nodes satisfying the predicate) requires cardinality estimation, which takes non-trivial time for a complex filter. For example, a recent histogram-based estimator (Zhu et al., 2021) takes approximately 0.2–0.5ms to perform a single cardinality estimation for a filter involving multiple attributes, which introduces a substantial overhead to the execution time of a similarity query.

To address this challenge, we adopt the following key observation: the optimizer only needs to rank different execution plans according to the optimization metric, rather than compute their exact values. Therefore, we design the metric to capture the effects of both graph density and the number of graphs, while structuring it so that only part of the metric can be quickly estimated to determine the relative ordering among different plans.

Search utility definition. We define the optimization metric on a set of proximity graphs that have disjoint nodes because this requirement simplifies both the definition and estimation of the metric. The metric under this requirement is sufficient for our optimization framework. Formally, we define search utility $U(G,p)$ to represent the efficiency of using a set of disjoint proximity graphs $G$ to process a similarity query with a filter predicate $p$:

(1) $$U(G,p)=\begin{cases}\displaystyle\frac{\text{card}(R,p)}{\sum_{g_{i}\in G}\text{card}(g_{i})\times|G|^{\alpha}},&\text{if $G$ covers $p$},\\[10.0pt] 0,&\text{otherwise.}\end{cases}$$

Here, $R$ represents the relation storing all tuples. The requirement that $G$ covers $p$ means $G$ must include all tuples in relation $R$ that satisfy $p$; otherwise, the utility is zero. The term $\text{card}(R,p)$ represents the total number of tuples passing $p$, and $\sum_{g_{i}\in G}\text{card}(g_{i})$ denotes the total number of tuples in $G$. Thus, their ratio, $\frac{\text{card}(R,p)}{\sum_{g_{i}\in G}\text{card}(g_{i})}$, captures the overall density of $G$ with respect to $p$. The factor $|G|^{\alpha}$ penalizes the use of a larger number of graphs, where $\alpha$ controls the intensity of this penalty. Our experiments show that setting $\alpha=0.4$ yields the best performance. The value of $U(G,p)$ is in $[0,1]$, where a higher value indicates higher search efficiency.

Estimation method. Estimating the exact value of $U(G,p)$ may be time-consuming because it requires computing the cardinality $\text{card}(R,p)$. Fortunately, $\text{card}(R,p)$ remains constant across different $G$s for the same predicate $p$. Therefore, to compare the utilities of different plans, it suffices to evaluate $\sum_{g_{i}\in G}\text{card}(g_{i})\times|G|^{\alpha}$ for ranking purposes. Computing $\text{card}(g_{i})$ is efficient, as the number of tuples in each proximity graph can be precomputed.

Figure 4. A tree-based graph index and a hash-based graph index built on the “citation count” and “topic” attributes.

3.3. Processing Conjunctions

Given a filter predicate in DNF $p=C_{1}\lor C_{2}\lor\cdots\lor C_{m}$, PathFinder first identifies a graph search plan (i.e., a subset of proximity graphs) for each conjunctive clause $C_{i}$ that has the highest search utility. Since enumerating the exponential number of possible graph search plans is prohibitively expensive, PathFinder employs a greedy algorithm to reduce the optimization time while still finding a high-quality graph search plan. For this and the next subsection, we only consider indexes on the attributes involved by $C_{i}$. We will discuss relaxing this assumption in Section 3.5.

Key ideas. PathFinder identifies up to two high-quality graph search plans that can process $C_{i}$ for each index and selects the one with the highest $U(G,C_{i})$ across all indexes. The two plans are complementary: the first includes a single proximity graph, while the second consists of multiple smaller and denser graphs. PathFinder efficiently finds these two plans by leveraging the monotonicity property of $U(G,C_{i})$: for two proximity graphs $g_{i}$ and $g_{j}$ where $g_{j}$ is a child of $g_{i}$ and both cover $C_{i}$, we have $U(\{g_{i}\},C_{i})>U(\{g_{j}\},C_{i})$ because $\text{card}(g_{j})$ is smaller than $\text{card}(g_{i})$.

Based on this property, for the first plan, PathFinder starts with the root node $g_{r}$ and recursively selects a child node to replace its parent until the child no longer covers $C_{i}$ or a leaf node is reached. Figure 4 shows an example of two indexes. If the predicate is: $(2\leq a_{c}\leq 10)\land a_{t}=\text{``DB''}$, PathFinder selects $\{g_{r}\}$ and $\{g_{10}\}$ as the first graph search plans for the tree index and hash index, respectively. This process yields a graph search plan consisting of a single proximity graph (denoted $g_{s}$) for each index.

If $g_{s}$ has child nodes, PathFinder further constructs the second graph search plan using its descendant nodes. This second plan complements the first by combining multiple smaller, denser graphs to process $C_{i}$. Specifically, PathFinder partitions $C_{i}$ based on the predicates of the child nodes of $g_{s}$ and selects up to one proximity graph to process each partition. Formally, $C_{i}=(C_{i}\land p_{s1})\lor\cdots\lor(C_{i}\land p_{sk})$, where $p_{sj}$ represents the predicate associated with the $j$th child of $g_{s}$. For each child node whose predicate $p_{sj}$ overlaps with $C_{i}$, PathFinder finds the proximity graph with the highest search utility within the subtree rooted at this child node, again leveraging the monotonicity property. Finally, the second plan consists of all proximity graphs selected for all partitions of $C_{i}$. The second plan, therefore, contains at most as many proximity graphs as the fan-out factor of the tree structure.

Consider the earlier predicate example $(2\leq a_{c}\leq 10)\land a_{t}=\text{``DB''}$ for the indexes in Figure 4. For the hash index, no second plan is generated. For the tree-based index, the first plan is $\{g_{r}\}$ and $g_{r}$ has three child nodes, two of which overlap with the input predicate (i.e., $g_{1}$ and $g_{2}$). The partition of the input predicate for $g_{1}$ is: $(2\leq a_{c}\leq 10)\land(0\leq a_{c}\leq 4)\land a_{t}=\text{``DB''}$, which can be simplified as: $(2\leq a_{c}\leq 4)\land a_{t}=\text{``DB''}$. Using this predicate to search the subtree of $g_{1}$, we select $g_{5}$ as it is a leaf node covering this predicate. Similarly, we select $g_{2}$ for the subtree rooted at $g_{2}$. So the second plan for the tree-based index is $\{g_{5},g_{2}\}$. Finally, PathFinder combines candidate plans from both indexes and chooses the one with the highest $U(G,C_{i})$ from the candidate set $\{\{g_{10}\},\{g_{r}\},\{g_{2},g_{5}\}\}$.

Input: $C_{i}$: a conjunctive clause, $I$: indexes involved by $C_{i}$

Output: A graph search plan for $C_{i}$

1

2$\mathcal{G}\leftarrow\emptyset$

3 foreach $I_{k}$ in $I$ do

4    $g_{r}\leftarrow$ the root node of $I_{k}$

5    $g_{s}\leftarrow$ FindSingleGraph $(g_{r},C_{i})$

6    $\mathcal{G}\leftarrow$ add $\{g_{s}\}$ to $\mathcal{G}$

7    if $g_{s}$ has child nodes then

8       $G\leftarrow$ FindSecondPlan $(g_{s},C_{i})$

9       $\mathcal{G}\leftarrow$ add $G$ to $\mathcal{G}$

10      

11   

12return $\arg\max_{G\in\mathcal{G}}U(G,C_{i})$

13

14Function FindSingleGraph ($g$, $p$):

15    if $g$ is leaf then

16       return $g$

17      

18   foreach $g_{c}$ in $g$’s child nodes do

19       if $g_{c}$ covers $p$ then

20          return FindSingleGraph ($g_{c}$, $p$)

21         

22      

23   return $g$

24   

25

26Function FindSecondPlan ($g_{s}$, $p$):

27    $G\leftarrow\emptyset$

28    foreach $g_{c}$ in $g_{s}$’s child nodes do

29       $p_{sc}\leftarrow g_{c}\text{'s predicate}$

30       if $p$ overlaps with $p_{sc}$ then

31          $g_{c}^{*}\leftarrow$ FindSingleGraph ($g_{c}$, $p\land p_{sc}$)

32          $G\leftarrow G\cup\{g_{c}^{*}\}$

33         

34      

35   return $G$

36   

Algorithm 1 Processing a conjunctive clause

Algorithm description. Algorithm 1 shows how PathFinder selects the graph search plan for a conjunctive clause $C_{i}$. Given the set of indexes $I$ involved by $C_{i}$, PathFinder enumerates each index $I_{k}$ to identify two candidate plans. It starts from the root node $g_{r}$ and calls FindSingleGraph to find the deepest graph $g_{s}$ that still covers $C_{i}$, leveraging the monotonicity of the utility function $U(G,C_{i})$. If $g_{s}$ has child nodes, PathFinder invokes FindSecondPlan to construct a complementary plan using multiple smaller proximity graphs. This function partitions $C_{i}$ by the predicates of the children of $g_{s}$ and finds the best proximity graph in each child’s subtree. For all candidate plans from all indexes, PathFinder selects the one with the highest search utility. The worst case of this algorithm will visit all $N$ nodes of all $M$ indexes, with the complexity of $O(N\times M)$.

Figure 5. A predicate with three conjunctive clauses on two attributes; tree-based indexes are built for both attributes.

3.4. Processing Disjunctions

The first phase of PathFinder’s optimization selects a graph search plan for each conjunctive clause $C_{i}$ of the filter predicate $p=C_{1}\lor C_{2}\lor\cdots\lor C_{m}$. To process disjunctions, one naïve method is to execute each plan one by one and combine their results. PathFinder, instead, considers merging these plans to optimize them.

Key ideas. The conjunctive clauses of a filter predicate may define value regions that are close to or overlap with each other. In such cases, the graph search plans selected for different conjunctive clauses may include proximity graphs that are duplicated or cover adjacent or overlapping regions. It is beneficial to deduplicate proximity graphs or replace smaller graphs with a larger one to further improve search utility.

Figure 5 illustrates this idea using an example filter predicate $p=C_{1}\lor C_{2}\lor C_{3}$ on two attributes, $a$ and $b$. Each clause $C_{i}$ corresponds to a rectangular value region. Assuming PathFinder selects $\{g_{9}\}$ to process both $C_{1}$ and $C_{2}$, we can merge the two plans to remove a redundant $g_{9}$. In addition, if PathFinder selects $\{g_{8}\}$ to process $C_{3}$, it might be beneficial to use $\{g_{r}\}$ to replace $\{g_{8},g_{9}\}$ to process all three conjunctive clauses, depending on the relative search utility of the two plans.

One thing to note is that for a set of proximity graphs $G$ belonging to the same index, we do not simply remove the proximity graphs in $G$ whose ancestor graph is also in $G$. This is because the ancestor may be sparse with respect to the input filter and searching only this sparse graph while removing smaller, denser graphs can harm recall, as verified by our experiments (omitted due to space limits). Instead, we consider replacing a subset of disjoint proximity graphs with their ancestor, allowing PathFinder to use the search utility metric to decide. Although this optimization is not optimal, it avoids costly cardinality estimation and keeps the optimization time small.

Input: $G$: the set of selected graphs for an index $I$; $p$: the filter predicate

Output: Optimized graph set

1

2foreach leaf node $g$ in $I$ do

3    $g.\text{plan}\leftarrow(g\in G)\;?\;\{g\}\;:\;\emptyset$

4   

5

6foreach non-leaf node $g_{p}$ in bottom-up order in $I$ do

7    $S\leftarrow\emptyset$

8    foreach child $g_{c}$ of $g_{p}$ do

9       $S\leftarrow S\cup g_{c}.\text{plan}$

10      

11   $p_{p}\leftarrow g_{p}\text{'s predicate}$

12    if $U(S,p\land p_{p})<U(\{g_{p}\},p\land p_{p})$ then

13       $g_{p}.\text{plan}\leftarrow\{g_{p}\}$

14       $G\leftarrow(G\setminus S)\cup\{g_{p}\}$

15      

16   else

17       if $g_{p}\notin G$ then

18          $g_{p}.\text{plan}\leftarrow S$

19         

20      else

21          $g_{p}.\text{plan}\leftarrow\{g_{p}\}$

22         

23      

24   

return $G$

Algorithm 2 Optimizing a set of graphs for an index

Algorithm description. Given the proximity graphs from the graph search plans of all conjunctive clauses, PathFinder deduplicates the graphs, groups them by index, and optimizes each group independently. Let $G$ denote the set of graphs selected from one index. PathFinder employs an optimization algorithm that iterates through non-leaf nodes from bottom-up and, for each node $g_{p}$, replaces the disjoint descendant graphs of $g_{p}$ in $G$ with $g_{p}$ itself if $g_{p}$ has a higher search utility, as shown in Algorithm 2. Specifically, each node $g$ maintains a variable $g.\text{plan}$ that records a set of disjoint graphs in $G$ and $g$’s subtree. This set of disjoint graphs serves as a candidate that may later be replaced by an ancestor graph. For a leaf node, $g.\text{plan}$ is initialized to ${g}$ if $g\in G$, and to $\emptyset$ otherwise. For each non-leaf node $g_{p}$, the algorithm collects the disjoint descendant graphs that could be replaced by ${g_{p}}$ (i.e., $S$) and compares their relative search utility values to decide whether to replace. If so, $g_{p}.\text{plan}$ is updated to $\{g_{p}\}$ and $G$ is updated accordingly (Lines 9–10). Otherwise, if $g_{p}\notin G$, we retain $S$ as the disjoint graph set to be replaced later. If $g_{p}\in G$, we instead start a new disjoint graph set by setting $g_{p}.\text{plan}$ to $\{g_{p}\}$ since $g_{p}$ overlaps with the graphs in $S$. In the worst case, the algorithm visits every node in every index, resulting in the same $O(N\times M)$ complexity as Algorithm 1.

3.5. Index Borrowing

The previous two subsections assume that, for a similarity query with a filter predicate $p$, PathFinder only leverages indexes built on the attributes involved in $p$. However, when two attributes $a$ and $b$ are correlated, it is beneficial to utilize an index built on attribute $a$ to process the filter predicate on the correlated attribute $b$ if no index is built on attribute $b$, rather than naïvely searching the root node $g_{r}$. For example, assume all tuples satisfying $b\leq 5$ also satisfy $a\leq 6$. To process $b\leq 5$, we can use the predicate $a\leq 6$ to find a graph search plan from the index built on $a$, and then apply the filter $b\leq 5$ during query execution to obtain the top-$K$ results.

Key ideas and algorithm. Assume that we want to use the index $I_{a}$ for attribute $a$ to process a predicate $p_{b}$ on attribute $b$. Our key ideas are: (1) synthesizing a predicate $p_{a}$ on attribute $a$ such that the tuples satisfying $p_{b}$ are a subset of those satisfying $p_{a}$ (i.e., $p_{a}$ covers $p_{b}$) while minimizing the number of tuples passing $p_{a}$; and (2) using the synthesized $p_{a}$ to find a graph search plan in $I_{a}$ via Algorithm 1, and apply $p_{b}$ during query execution. We require that $p_{a}$ covers $p_{b}$ to ensure the graph search plan selected for $p_{a}$ includes all tuples defined by $p_{b}$.

To quickly synthesize $p_{a}$ from $p_{b}$, PathFinder precomputes, for each proximity graph in $I_{a}$, the value range of attribute $b$ among its tuples. In a hash-based index $I_{a}$, each proximity graph corresponds to a categorical value of attribute $a$. For each graph, PathFinder checks whether its value range for attribute $b$ (denoted as $g.p_{b}$) overlaps with $p_{b}$. If so, the corresponding categorical value of $a$ is added to a set $C$. Finally, PathFinder synthesizes the predicate $p_{a}$ as “$a\text{ IN }C$”. For a tree-based index, we aim to synthesize a range predicate $p_{a}$ from $p_{b}$. The key idea is to determine the minimum and maximum boundaries for $p_{a}$ by scanning the leaf nodes of the tree-based index and checking for overlap with $p_{b}$. Specifically, to find the minimum boundary, we scan the leaf nodes from left to right and, for each proximity graph $g$, check whether $g.p_{b}$ overlaps with $p_{b}$. This process stops at the first $g$ that overlaps with $p_{b}$ and the minimum value of $g.p_{a}$ is then used as the lower boundary of $p_{a}$. Similarly, we scan the leaf nodes from right to left to determine the maximum value of $p_{a}$.

Figure 6. A tree-based index built on attribute $a$. It includes attribute $b$’s value ranges (i.e., $p_{b}$) for the leaf nodes.

Example. Figure 6 shows an example of a tree-based index built on attribute $a$. Each node records the value ranges of attributes $a$ and $b$ that its tuples fall into, denoted as $g.p_{a}$ and $g.p_{b}$, respectively. For example, the tuples in $g_{3}$ satisfy $a\leq 4$ and $b\leq 6$. Given a predicate $p_{b}:b\leq 6$, PathFinder determines that it overlaps only with $g_{3}$ and $g_{4}$, synthesizes $p_{a}:a\leq 8$, and uses $p_{a}$ to construct a graph search plan for the index, which could be $\{g_{1}\}$ or $\{g_{3},g_{4}\}$, depending on the search utility values. During query execution, PathFinder uses the original predicate $p_{b}:b\leq 6$ to filter the tuples.

Application to arbitrary filters. This optimization can be generalized to filters on multiple attributes. Given a predicate $p=C_{1}\lor C_{2}\lor\cdots\lor C_{m}$, PathFinder examines each conjunctive clause $C_{i}$ to determine whether it contains an atomic predicate, say $p_{b}$, on an attribute $b$ for which no ANNS index exists. If such $p_{b}$ exists, PathFinder selects an index whose attribute, say $a$, is most correlated with $b$ but is not involved in $C_{i}$ to process $p_{b}$. Then, we synthesize a predicate $p_{a}$ from $p_{b}$ and replace $p_{b}$ with $p_{a}$ in $C_{i}$, resulting in a new clause $C_{i}^{\prime}$. Finally, we construct the updated predicate $p^{\prime}=C_{1}^{\prime}\lor C_{2}^{\prime}\lor\cdots\lor C_{m}^{\prime}$ to generate the graph search plan using Algorithms 1–2. During query execution, the executor applies the original predicate $p$.

4. Implementation

We implement a prototype of PathFinder in C++. It allows users to load a collection of data objects along with their attributes and embeddings as a database relation. Each tuple in the relation is automatically assigned a unique integer primary key, and a primary index is created to locate tuples by this key. The primary index is implemented as either a B⁺-tree (for update support) or an array (for read-only workloads), with B⁺-tree as the default.

Users can selectively build either tree-based or hash-based indexes on a subset of attributes to efficiently support filtered ANNS. The tree-based index is implemented as a multi-way tree on an attribute (Xu et al., 2024; Jiang et al., 2025b), where each node represents a subrange of the attribute’s values. For each node, PathFinder builds a Vamana graph (Jayaram Subramanya et al., 2019) over the tuples contained in that node’s subrange. The graph is constructed on the primary keys of these tuples, with primary keys serving as vertex IDs. During graph search, PathFinder uses the primary keys to access the corresponding tuple’s attributes and vectors using the primary index. The fan-out factor of a tree-based index is configurable and set to 2 by default. For hash-based indexes, PathFinder also uses Vamana graphs as the proximity graphs. The updates to tree-based indexes can be handled by an existing method (Jiang et al., 2025b) and updates to hash-based indexes can be handled by the existing methods for updating proximity graphs (Singh et al., 2021).

Users can issue similarity queries with filters. For each query, PathFinder generates a graph search plan, searches each proximity graph in this plan to obtain intermediate top-$K$ results, and merges them to get the final top-$K$ results. PathFinder employs a best-first search strategy optimized for filtered ANNS, referred to as out-of-range search (Xu et al., 2024; Ait Aomar et al., 2025). When exploring a vertex’s neighbors, this strategy considers all neighbors (including those that do not satisfy the filter) as candidates for further expansion, while using a separate queue for maintaining the top-$K$ results passing the filter.

5. Evaluation

We evaluate PathFinder to answer the following research questions:

• What are the end-to-end performance benefits of PathFinder for filtered ANNS workloads with conjunctive predicates? (Section 5.2)

• What are the end-to-end performance benefits of PathFinder for filtered ANNS workloads with mixed conjunctive and disjunctive predicates? (Section 5.3)

• What are the performance benefits of the index-borrowing optimization under different levels of attribute correlation? (Section 5.4)

• How does the $\alpha$ parameter in search utility impact the performance of PathFinder? (Section 5.5)

• How do different index sizes affect query performance, index construction time, and memory overhead? (Section 5.6)

5.1. Experimental setup

We run all experiments in a machine that includes an AMD EPYC 9454 CPU and 256 GB local DRAM. We use Ubuntu 20.04 as the OS and 16 threads for all baselines.

(a) Low-selectivity queries (0.1%–1%)

(b) Medium-selectivity queries (1%–10%)

(c) High-selectivity queries (10%–100%)

Figure 7. QPS (queries per second) vs. recall on filters with conjunctive predicates

(a) Predicates with one attribute

(b) Predicates with two attributes

(c) Predicates with three attributes

Figure 8. Evaluation on filters with conjunctive predicates that involve different number of attributes (RedCaps)

(a) Low-selectivity queries (0.1%–1%)

(b) Medium-selectivity queries (1%–10%)

(c) High-selectivity queries (10%–100%)

Figure 9. QPS vs. recall on filters with mixed disjunctive and conjunctive predicates

Baselines. We choose existing approaches that support filters comprising conjunctions and disjunctions on numerical and categorical attributes, as well as a baseline we implement that naïvely leverages attribute-specific indexes. Specifically, we include two basic search strategies: 1) pre-filtering search, which directly computes distances to all data objects that pass the filter without using any ANNS index (denoted as Pre-filtering), and 2) in-filtering search, which performs best-first search on a Vamana graph (Jayaram Subramanya et al., 2019) but only explores vertices that satisfy the filter (denoted as In-filtering Vamana). We omit the post-filtering strategy because its performance is dominated by the out-of-range search baseline (Ait Aomar et al., 2025; Xu et al., 2024), which explores all neighbors in a Vamana graph while maintaining a separate queue for the top-$K$ candidates that satisfy the filter, denoted as OOR Vamana. We choose the Vamana graph for all baselines since it is widely adopted in industry (Jayaram Subramanya et al., 2019; mil, 2025; Adams et al., 2025) and is also used by PathFinder. We use ACORN (Patel et al., 2024) as another baseline, which selectively materializes additional edges to preserve graph density under selective filters and adopts the in-filtering search strategy.

We additionally implement a new baseline, RandomSelect, which converts the filter predicate into DNF, gets the top-$K$ results for each conjunctive clause separately, and combines the results. For each conjunctive clause, it randomly selects one of the attribute-specific indexes referenced by the conjunction and applies an existing search algorithm on that index. For the tree-based index, we adopt iRangeGraph (Xu et al., 2024) as it supports a conjunctive predicate that involves the attribute this index is built on. For the hash-based index, we search all proximity graphs involved in the predicate using the out-of-range search and merge their results. All baselines are implemented in the PathFinder codebase for a fair comparison.

Configurations. For the Vamana graph, we set the parameter for robust pruning to $\alpha=1.2$ (Jayaram Subramanya et al., 2019). For the tree-based index, we use a fan-out factor of 2 and a tree height of 7. We build attribute-specific indexes for all attributes of the datasets. In Section 5.6, we vary the tree height and the number of available indexes to evaluate their impact. PathFinder and RandomSelect use the same attribute-specific indexes. We use $\alpha=0.4$ for estimating the search utility (Equation 1) For ACORN, we use $M_{\beta}=128$ and $\gamma=80$. We report the tradeoff between the query throughput and the average recall@10 by varying the search queue length of the best-first search from 10 to 3,000 for all approaches.

Table 1. Datasets used in the evaluation

	#Rows	#Dim.	Numeric Attr.	Categorical Attr.
ArXiv	132K	768	publication year citation count	classification (142 distinct values)
RedCaps	6.9M	512	post time upvote count	subreddit category (350 distinct values)
SIFT	1M	128	4 decimals	N/A
GIST	1M	960	4 decimals	N/A

Benchmarks. We evaluate PathFinder and all baselines on four real-world datasets, summarized in Table 1. ArXiv is a dataset of research papers from the arXiv repository, where vector embeddings are generated from paper abstracts (arx, 2025). RedCaps is an image dataset with attributes extracted from Reddit (red, 2025). We use two numeric and one categorical attribute for both datasets. SIFT and GIST are standard benchmarks for evaluating ANNS algorithms (sif, 2025). For each of them, we create four attributes of decimal numbers, with the first two correlated and the last two independent. To generate correlated attributes, we sample one attribute $a$ from a standard Gaussian distribution and then generate another attribute $b$ using the formula $b=a+k\times norm$, where $norm$ follows the standard Gaussian distribution. The parameter $k$ controls the correlation level. We set $k=0.5$ for SIFT and $k=0.1$ for GIST to introduce different levels of correlation. The values of the last two attributes are uniformly sampled from the value range [0, 1000]. To build the Vamana graph and ACORN, we set the max neighbor degree $M$ to 32 for SIFT and 64 for all other datasets.

To generate similarity queries, we use the queries provided with the datasets (for SIFT and GIST) or extract a random sample of data objects from the dataset and exclude them from the dataset (for ArXiv and RedCaps). Filters are generated by combining two templates of atomic predicates on different attributes using conjunctions and disjunctions. The first template is $min\leq a\leq max$, where $a$ is a numeric attribute and $min$/$max$ values are configurable. The second one is $a\text{ IN }C$, where $a$ is a categorical attribute and $C$ is a set of categorical values. For each test, we generate 1K filtered similarity queries and scan the dataset to obtain the ground truth.

5.2. Performance on Conjunctive Predicates

In this subsection, we evaluate PathFinder and all baselines under filtered ANNS workloads with conjunctive predicates. We generate a conjunctive predicate by randomly creating atomic predicates over all attributes and combining two or three of them using conjunctions. We group these predicates by selectivity and the number of attributes involved and evaluate them separately.

Varying selectivity level. For each dataset, we construct three groups of filters with different selectivity levels: low (0.1%–1%), medium (1%–10%), and high (10%–100%), with each group having 1K queries. Figure 7 presents the QPS (queries per second) and recall curves across all selectivity levels and datasets. We observe that PathFinder can achieve nearly 1.0 recall across all workloads, while all baselines except Pre-filtering fall short. Pre-filtering always has perfect recall because it directly computes distances without using ANNS indexes; however, PathFinder has substantially higher QPS than Pre-filtering. PathFinder consistently outperforms all other baselines under low- and medium-selectivity workloads, and achieves comparable or better performance under high selectivity. This is because PathFinder can effectively utilize attribute-specific indexes by quickly constructing an efficient graph search plan using the search utility metric and the optimization algorithms. For example, compared to RandomSelect, the strongest baseline for low- and medium-selectivity workloads, PathFinder achieves 18.4$\times$ higher QPS at recall=0.9 (i.e., for RedCaps in Figure 7). RandomSelect performs better than other baselines because it can leverage attribute-specific indexes, whereas In-filtering Vamana suffers from low recall due to the sparsity of filtered graphs under low- and medium-selectivity workloads. The optimization overhead of PathFinder (included in the reported QPS and recall curves) is small, accounting for only 0.12%–5.43% of the total end-to-end execution time across the four datasets. RedCaps exhibits the lowest relative overhead (0.12%) due to its large number of data objects, whereas ArXiv shows the highest overhead (5.43%).

Varying the number of attributes. Next, we categorize the conjunctive predicates in the RedCaps dataset by the number of attributes involved (two or three) and additionally construct a group of single-attribute predicates. Each group contains 1K queries, with one-third of the queries corresponding to each selectivity level. Figure 8 shows that PathFinder achieves a better tradeoff between QPS and recall than all baselines. PathFinder outperforms RandomSelect on single-attribute predicates because its cost-based optimization framework can generate an execution plan that searches the tree-based or hash-based index more efficiently than the baseline approaches used by RandomSelect. These results show that the cost-based optimization in PathFinder not only benefits multi-attribute filters but also improves performance for single-attribute filters.

5.3. Performance on Mixed Conjunctive and Disjunctive Predicates

Now we evaluate filtered ANNS workloads with mixed conjunctive and disjunctive predicates. We generate such a predicate by first generating two conjunctive or atomic predicates (using the method from Section 5.2) and connecting them using a disjunction. For each dataset, we evaluate three groups of predicates, each corresponding to a selectivity level. Figure 9 shows that PathFinder can achieve almost 1.0 recall for all workloads while the baselines (except Pre-filtering) cannot and PathFinder has a stronger QPS and recall tradeoff than all baselines for the low- and medium-selectivity workloads. Specifically, PathFinder has 9.8$\times$ higher QPS than RandomSelect, the strongest baseline, at recall 0.95 (i.e., for RedCaps in Figure 9). The optimization overhead of PathFinder is also small in these tests, accounting for 0.11%–3.33% of the total execution time across the four datasets. PathFinder shows slightly lower performance than OOR Vamana for high-selectivity workloads when the recall is below 0.9, because PathFinder may search proximity graphs across different indexes, whereas OOR Vamana searches only a single graph.

(a) High correlation (k=0.05) (b) Medium correlation (k=0.1) (c) Low correlation (k=0.2) Figure 10. Evaluation of index borrowing under varying attribute correlations (SIFT) Figure 11. The performance impact of the $\alpha$ parameter

Figure 12. Performance impact of using different numbers of layers for the tree-based indexes (RedCaps)

(a) Two indexes available

(b) One index available

Figure 13. Varying the number of available indexes (RedCaps)

5.4. Performance of Index Borrowing

We next evaluate the performance benefits of the index borrowing optimization under different levels of attribute correlation. Recall that we synthesize a pair of correlated attributes for the SIFT and GIST datasets using the formula $b=a+k\times norm$, where $a$ is an attribute generated from a standard Gaussian distribution, and $norm$ is another standard Gaussian variable. By varying the value of $k$, we control the strength of the correlation between $a$ and $b$. In this experiment, we build an attribute-specific index on one of the correlated attributes and issue queries with filters on the other. We generate 1K queries, with one-third of the queries corresponding to each selectivity level.

Figure 11 shows the QPS and recall curves for PathFinder with and without the index borrowing optimization under three different $k$ values for the SIFT dataset. In the setting without index borrowing, PathFinder searches the root graph using the out-of-range search strategy. We observe that the index borrowing optimization significantly improves performance when the attributes are highly correlated (e.g., $k=0.05$), and that the performance gain gradually diminishes as the correlation weakens. Specifically, the index borrowing optimization improves QPS by up to 2.44$\times$ at recall=0.95. The results for the GIST dataset exhibit the same trend and are omitted due to space limitations.

5.5. Performance Impact of the $\alpha$ Parameter

We evaluate the performance impact of the $\alpha$ parameter in the search utility function. As defined in Equation 1, $\alpha$ controls the penalty for searching multiple proximity graphs: a larger $\alpha$ value discourages the optimizer from selecting multiple graphs. We study its performance impact by evaluating predicates on the categorical attribute of the RedCaps dataset with varying $\alpha$ value. This attribute includes 350 distinct values. We generate 1K predicates, each randomly selecting up to 30 attribute values (i.e., using the $a\text{ IN }C$ template). In this setting, PathFinder needs to choose between using the root graph or the hash-based index that searches multiple proximity graphs. Figure 11 shows that $\alpha=1.0$ results in the lowest performance, as it over-penalizes the use of multiple graphs and forces PathFinder to use the single root graph. Conversely, $\alpha=0.0$ does not achieve the best performance either, as it causes the optimizer to always use the hash-based index and search too many graphs. We find that $\alpha=0.4$ and $\alpha=0.6$ offer the best tradeoff between recall and QPS; therefore, we set $\alpha=0.4$ as the default value in our experiments.

5.6. Performance Impact of Varying Index Sizes

We now evaluate the performance impact of different index sizes by varying 1) the number of layers in the tree-based indexes and 2) the number of indexes available.

Since our default configuration builds 7 layers of tree-based indexes, we vary this number from 6 to 2 and report the query performance and indexing overhead. Figure 12 shows the QPS and recall curves for the mixed conjunctive and disjunctive predicates at the low-selectivity level for the RedCaps dataset. For the same QPS, the recall of both PathFinder and RandomSelect drops as we reduce the number of layers for the tree-based indexes. The peak recall of RandomSelect drops significantly, from 0.98 to 0.54, while PathFinder maintains a recall close to 1.0. Even with 3 layers, PathFinder still achieves a better QPS–recall tradeoff than all other baselines. For example, at a recall of 0.85, PathFinder has 3.1$\times$ higher QPS than OOR Vamana. When using only 2 layers, PathFinder shows a similar performance to OOR Vamana for recall below 0.7, but has a stronger tradeoff between QPS and recall and the maximum recall in other cases.

Table 2 and Table 3 report the index construction time and index sizes for all datasets when building indexes for all attributes, respectively. Although PathFinder takes a longer index construction time than the Vamana graph, its construction time is substantially smaller than that of ACORN. PathFinder consumes more memory than both ACORN and Vamana, but reducing the number of layers from 7 to 2 cuts memory usage by 3.7$\times$ on average while still allowing PathFinder to outperform all baselines on query performance. An interesting direction for future work is to compress attribute-specific indexes to reduce memory overhead.

Next, we vary the number of indexes available on the RedCaps dataset. Since RedCaps has three attributes, we construct six index configurations, each having indexes available on two or one attribute. We evaluate the mixed disjunctive and conjunctive predicates from the low-selectivity group under each configuration and aggregate the QPS and recall results by the number of indexes available. Figure 13 show that while the performance gains of PathFinder decrease as fewer indexes are available, it consistently outperforms all baselines. For example, when two indexes are available, PathFinder has 1.82$\times$ higher QPS than RandomSelect at recall=0.95.

Table 2. Time to Index (s)

	SIFT	GIST	ArXiv	RedCaps
ACORN	684.8	5633.2	86.3	31483.3
Vamana	12.9	162.3	4.0	389.1
PathFinder – 2 layers	68.1	762.8	8.7	1147.5
PathFinder – 3 layers	110.3	1235.1	13.8	1830.5
PathFinder – 4 layers	143.8	1599.6	17.4	2407.8
PathFinder – 5 layers	169.2	1865.2	20.2	2887.9
PathFinder – 6 layers	190.3	2052.1	22.1	3274.4
PathFinder – 7 layers	208.1	2187.4	23.4	3548.9

6. Related Work

We discuss the related work on ANNS, filtered ANNS, and access path selection in vector databases.

ANNS. There has been extensive research on ANNS indexes, which can be broadly categorized into hashing-based (Tao et al., 2009; Tian et al., 2024), clustering-based (Chen et al., 2021; Guo et al., 2020), and graph-based (Malkov and Yashunin, 2020; Malkov et al., 2014; Fu et al., 2019; Subramanya et al., 2019) approaches. We focus on graph-based methods because they provide an excellent tradeoff between QPS and recall (Fu et al., 2019; Malkov and Yashunin, 2020; Subramanya et al., 2019), and have been adopted in nearly all modern vector databases (Wang et al., 2021; Wei et al., 2020; pgv, 2025; chr, 2025; lan, 2025). Among them, HNSW (Malkov and Yashunin, 2020) and Vamana (Subramanya et al., 2019) are the most widely adopted ones. PathFinder adopts the Vamana graph as its proximity graph.

Filtered ANNS. Graph-based indexes support filtered ANNS using either the in-filtering or post-filtering strategy. Recent studies have explored new techniques to further improve filtered ANNS performance. ACORN (Patel et al., 2024) supports arbitrary filters and enhances performance by materializing additional edges and utilizing 2-hop search. Two recent works (Mohoney et al., 2023; Li et al., 2025) support complex filters by materializing filter-specific graph indexes tailored to a known filter workload, an assumption that PathFinder does not make. Another line of research focuses on attribute-specific indexes. Several studies have proposed graph-based indexes for range filters on numeric data (Zuo et al., 2024; Xu et al., 2024; Engels et al., 2024; Jiang et al., 2025b; Wang et al., 2025; Liang et al., 2025). Among these, tree-based indexes are the most popular (Wang et al., 2025; Engels et al., 2024; Xu et al., 2024; Jiang et al., 2025b) and have also been extended to support updates (Jiang et al., 2025b; Wang et al., 2025). Other papers target label data (Cai et al., 2024; Gollapudi et al., 2023; Gupta et al., 2023; Wang et al., 2023; Ait Aomar et al., 2025).

PathFinder differs from these approaches in that it serves as a unified indexing framework that leverages attribute-specific indexes to efficiently handle complex filters with conjunctions and disjunctions. It supports both numeric and categorical attributes and achieves state-of-the-art performance on filtered ANNS workloads over these data types. PathFinder supports label data using the root graph. Extending PathFinder to support attribute-specific indexes for label data is left for future work.

Access path selection. Relational databases allow administrators to build indexes on selective attributes and employ an access path selection framework to determine how best to utilize these indexes (Selinger et al., 1979; Kester et al., 2017). Recent studies on vector databases have also proposed new access path selection frameworks (Wei et al., 2020; Wang et al., 2021; Sanca and Ailamaki, 2024), but they focus on choosing among the three basic search strategies: pre-filtering, in-filtering, and post-filtering. In contrast, PathFinder focuses on leveraging attribute-specific ANNS indexes to improve the performance of filtered ANNS, and is therefore complementary to the aforementioned frameworks.

Table 3. Index Size (GB)

	SIFT	GIST	ArXiv	RedCaps
ACORN	0.56	0.59	0.08	4.24
Vamana	0.12	0.16	0.02	1.31
PathFinder – 2 layers	0.59	0.81	0.08	5.11
PathFinder – 3 layers	1.07	1.45	0.12	7.67
PathFinder – 4 layers	1.53	2.08	0.16	10.21
PathFinder – 5 layers	2.00	2.70	0.20	12.72
PathFinder – 6 layers	2.46	3.30	0.23	15.15
PathFinder – 7 layers	2.91	3.89	0.26	17.29
(Raw Vectors)	0.48	3.58	0.35	13.24

7. Conclusion

This paper introduces PathFinder, an indexing framework designed for filtered ANNS. PathFinder allows DBMS administrators to create attribute-specific ANNS indexes on selective attributes and adopts a cost-based optimization framework to effectively utilize these indexes for improving the performance of filtered ANNS. The efficiency of PathFinder stems from three key innovations: the optimization metric for quantifying the tradeoff between search time and accuracy, the optimization algorithms for processing filters with conjunctions and disjunctions, and the index borrowing technique that enables leveraging one attribue-specific index to process filters on correlated attributes. Extensive experiments show that PathFinder significantly improves the performance of filtered ANNS with conjunctive and disjunctive filters.