Tags: zama-ai/fhevm
Tags
fix(coprocessor): add (chain_id, block_number) index on host_chain_bl… ( #2739) fix(coprocessor): add (chain_id, block_number) index on host_chain_blocks_valid (#2499) * fix(coprocessor): add (chain_id, block_number) index on host_chain_blocks_valid Adds the missing (chain_id, block_number) index on host_chain_blocks_valid. Migration 20260319120000_add_block_number_for_state_revert.sql added analogous (host_chain_id, block_number) indexes to three sibling tables (`computations`, `pbs_computations`, `allowed_handles`) to support state-revert queries. It missed host_chain_blocks_valid, even though that table has the same access pattern via `update_block_as_finalized` in host-listener/src/database/tfhe_event_propagate.rs. Built transactionally (plain CREATE INDEX): at current deployment sizes (~1.36M rows on testnet, ~230k on dev) the brief ACCESS EXCLUSIVE lock is sub-second on dev and well under 10s on testnet — within the host-listener's WS subscription timeout budget. CONCURRENTLY is reserved for the larger-table case via initialize_db.sh's precreate_index helper. Main only, no backport. Follow-up to fhevm-internal#1369 (closed not-planned, since the originally hypothesized "slow scan on growing table" framing was disproved by direct measurement) and fhevm-internal#1383. Closes zama-ai/fhevm-internal#1383 * chore(coprocessor): trim migration comment, drop unverified mainnet claim Tighten the comment in 20260513120000_add_block_number_index_on_host_chain_blocks_valid.sql per review feedback: drop the unverified "if this approaches mainnet scale (multi-million rows)" framing (mainnet is actually smaller than testnet on this stack) and keep only what's necessary: what the index is, where the pattern comes from, and which function uses it. Co-authored-by: Elias Tazartes <66871571+Eikix@users.noreply.github.com>
PreviousNext