What is efConstruction?

efConstruction is the parameter that controls how wide a search HNSW performs while looking for candidate neighbors during index construction — specifically, how many candidates the search-layer routine keeps track of when it’s trying to find good connections for a newly inserted node. A larger efConstruction means the construction process considers a broader, more thorough set of candidates before the neighbor-selection heuristic picks the final connections to keep, generally producing a higher-quality graph at the cost of slower index building, which makes it one of the central levers for trading construction time against the eventual search quality of the finished index.

What role does efConstruction actually play during a single node’s insertion?

When a new vector is inserted, HNSW needs to find good candidate neighbors for it at each layer it will participate in, and it does this by running a search — very similar in structure to the search used to answer queries later on — starting from the current entry point and working down through the hierarchy. At the layers where the new node actually needs connections, this search uses efConstruction as its target result-set size, meaning it keeps track of the efConstruction closest candidates found so far, rather than stopping as soon as it finds just M or Mmax0 of them. Once this search finishes, the neighbor-selection heuristic runs over this larger candidate pool and picks out the actual connections to keep, typically a smaller number set by M or Mmax0. A larger efConstruction gives the heuristic a richer, more thorough pool of candidates to choose from, increasing the odds that the connections ultimately selected are genuinely good ones rather than merely the best options that happened to be found within a narrower search.

This distinction between the width of the construction-time search and the number of connections actually kept is worth being precise about: efConstruction isn’t the number of neighbors a node ends up with — that’s controlled by M and Mmax0 — it’s the size of the candidate pool the neighbor-selection heuristic gets to choose from before narrowing that pool down to the final connections.

Why does a wider candidate search during construction actually improve the finished graph’s quality?

A narrow construction-time search risks missing genuinely good neighbor candidates simply because they weren’t found before the search stopped, which can leave a node connected to a set of neighbors that are locally decent but not truly optimal, given what else was actually available nearby in the vector space. A wider search, by considering more candidates before the heuristic makes its final selection, gives the diversified neighbor-selection process a better chance of finding and keeping the genuinely most useful connections — ones that not only sit close to the new node but also help spread its connectivity across different directions in the surrounding space, exactly the kind of well-diversified neighbor set that makes a graph easy for a later greedy search to traverse accurately.

This effect compounds across an entire index build: since every node’s connections depend partly on the quality of the candidate search run during its own insertion, a consistently wider efConstruction across the whole construction process tends to produce a graph with generally better-chosen connections throughout, which shows up directly as improved recall once the finished index is actually searched.

What does increasing efConstruction actually cost, and how should it be chosen in practice?

The cost is almost entirely paid at build time rather than at query time: a larger efConstruction means each insertion’s candidate search explores more of the graph, directly increasing how long the overall index build takes, particularly noticeable on large datasets where construction time can already run into hours. Because efConstruction only affects the one-time construction process rather than the ongoing cost of every future query, many practitioners are willing to set it considerably higher than they would set the analogous query-time parameter, efSearch, since a slower one-time build is often an easy trade to make in exchange for a permanently better-quality graph that every subsequent query benefits from.

In practice, efConstruction is typically set well above M — commonly somewhere in the range of one hundred to several hundred — with the exact value chosen through the same kind of empirical, benchmark-driven process used for the rest of HNSW’s parameters: build the index with a candidate value, measure the resulting recall against a representative workload, and increase efConstruction further if recall falls short, accepting the corresponding increase in build time as the cost of that improvement.

Having covered how efConstruction shapes the quality of the graph produced during construction, the M-parameter and neighbor-selection-heuristic glossary pages are worth revisiting together with this fuller picture, since efConstruction’s entire value comes from feeding a richer candidate pool into exactly that heuristic. From there, the efSearch glossary page is the natural point of comparison, covering the equivalent parameter used at query time and clarifying exactly how the two related but distinct settings differ in what they cost and when that cost gets paid.