Previously, the cost estimation formula for a HNSW index scan utilized
a methodology that only factored in the entry level for an HNSW scan
and the "m" index parameter, which reflects the number of tuples (or
vectors) to scan at each step of a HNSW graph traversal. While this
would bias the PostgreSQL query planner to choose an HNSW index scan
over other available paths, this could lead to potential suboptimal
index selection, for example, choosing to use a HNSW index instead of
an available B-tree index that has better selectivity.
The number of tuples scanned during HNSW graph traversal is principally
influenced by these factors:
* The number of tuples stored in the index
* `m` - the number of tuples that are scanned in each step of the graph
traversal
* `hnsw.ef_search` - which influences the total number of steps it
takes for the scan to converge on the approximated nearest neighbors
Through testing different source models for vectors, we also observed
that the correlation of vectors in mdoels would impact this convergence.
For this first iteration, we've opted to hardcode a constant scaling
factor and set it to `0.55`, though a future commit may turn this into
a configurable parameter.
The high-level formula for estimating the cost of a HNSW index scan is
as such:
```
(entryLevel * m) + (layer0TuplesMax * layer0Selectivity)
```
where
- `(entryLevel * m)` is the lower bound of tuples to scan, as it
accounts for the graph traversal to layer 0 (L0). (L1 and above has an ef=1)
- `layer0TuplesMax` is an estimate of the maximum number of tuples to
scan at L0. This accounts for tuples that may end up being discarded due
to them already being visited. Testing shows that the number of steps
until converge is similar to the value of `hnsw.ef_search`, thus we can
estimate tuples max at `hnsw.ef_search * m * 2`
- `layer0Selectivity` - estimates the percentage of tuples that will
actually be scanned during the index traversal, multipled by the scaling
factor
In addition to the `m` build parameter and `hsnw.ef_search`, costs
estimates can be influenced by standard PostgreSQL costing parameters,
though adjusting those (e.g. `random_page_cost`) should be done with
care.
Co-authored-by: @ankane
With elog(), you get XX000 "internal_error", which sounds scary.
It's not self-evident what the right error codes for some of these
errors are, but I tried to use my best judgment.
