risingwavelabs/risingwave · error

should be set for vector index

Error message

should be set for vector index

What it means

A `VecDimensionError`/panic-style assertion in `gen_create_index_plan` (create_index.rs:399) fired while building the `PbVectorIndexInfo` for a vector index. The parsed AST carried an optional HNSW dimension (`dimension: Option<i32>`), and it was `None` at plan time. RisingWave requires an explicit `DIMENSION` option on `CREATE INDEX ... USING HNSW` because the vector column type must have a fixed, known dimension to build the index table and the protobuf vector index info.

Source

Thrown at src/frontend/src/handler/create_index.rs:399

            "inner_product" => PbDistanceType::InnerProduct,
            "cosine" => PbDistanceType::Cosine,
            other => {
                return Err(ErrorCode::InvalidInputSyntax(format!(
                    "unsupported vector index distance type: {}",
                    other
                ))
                .into());
            }
        };

        let vector_index_write = input.gen_vector_index_plan(
            index_table_name.clone(),
            index_database_id,
            index_schema_id,
            definition,
            retention_seconds,
            PbVectorIndexInfo {
                dimension: dimension.expect("should be set for vector index") as _,
                config: Some(vector_index_config),
                distance_type: distance_type as _,
            },
        )?;
        let index_table = vector_index_write.table().clone();
        let plan: PlanRef = ensure_sync_log_store_fragment_root(vector_index_write.into());
        (plan, index_table)
    } else {
        // Manually assemble the materialization plan for the index MV.
        let materialize = assemble_materialize(
            index_database_id,
            index_schema_id,
            table.clone(),
            context.clone(),
            index_table_name.clone(),
            &index_columns_ordered_expr,
            &include_columns_expr,
            // We use the first index column as distributed key by default if users

View on GitHub (pinned to 6469eb736d)

Solutions

1. Ensure the indexed column is declared with a fixed dimension, e.g. `ALTER`/recreate the table with `vec VECTOR(3)` instead of an untyped or wrong-typed column.
2. Verify the CREATE INDEX statement targets a `VECTOR(n)` column and specifies `DISTANCE TYPE` options correctly.
3. If hit internally, fix upstream code to always set the dimension before calling `gen_create_index_plan` instead of relying on `expect`.
4. Check the table's schema via `\d t` / `information_schema.columns` to confirm the column type carries a dimension.

Example fix

// before
CREATE INDEX idx ON t USING HNSW (vec ascii_cosine_ops); -- vec is not VECTOR(n)
// after
ALTER TABLE t ADD vec3 VECTOR(3);
CREATE INDEX idx ON t USING HNSW (vec3 ascii_cosine_ops);

-- before CREATE INDEX, confirm the column type has a fixed dimension
SELECT data_type FROM information_schema.columns
WHERE table_name = 't' AND column_name = 'vec';
-- must look like: VECTOR(3), not BYTEA/JSON or dimensionless VECTOR

When it happens

Trigger: Calling the create-index handler with `vector_index_mode = VectorIndexMode::Hnsw` but a dimension that could not be derived — e.g. `CREATE INDEX ... USING HNSW ON t (ORDER BY vec ASC)` where `vec`'s declared type is not a fixed-dimension vector type, or internal callers constructing a vector index plan without setting the dimension field in the binder/planner.

Common situations: Indexing a column whose type is `BYTEA`/JSON instead of `VECTOR(n)`; the column being declared `VECTOR` without a dimension (`VECTOR` with no length, if allowed by the create-table statement); SQL passed through from tools that omit the dimension; bugs in internal table-creation flows (e.g. iceberg engine tables) that build vector indexes on untyped columns.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors

• relative_error={} does not satisfy 0.0 < relative_error < 1.
• {} must contain 1 argument
• {object_type} not found: {name}
• Not supported: {0}\nHINT: {1}
• Bind error: {0}

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/7790df3c5bbc8c49. Report an issue: GitHub.