HypoPG 1.4.5 fixes crash bug and long-standing estimation error in hypothetical indexes
The PostgreSQL extension for testing hypothetical indexes without physical creation patches a crash-triggering relid handling flaw and corrects a persistent estimation bug in hypo_estimate_index.
Summary
HypoPG 1.4.5, a maintenance release of the PostgreSQL extension for hypothetical indexes, addresses two bugs reported by users and fixed by maintainer Julien Rouhaud. The extension allows database administrators to evaluate whether potential indexes would improve query performance without actually building them, supporting PostgreSQL versions from 9.2 onward.
This release corrects a crash vulnerability related to relid handling in hypothetical indexes and fixes what the changelog describes as a long-standing thinko in the hypo_estimate_index function. Both fixes are confined to bug correction with no new features or API changes introduced.
What fixes arrive in HypoPG 1.4.5
- hypo_estimate_index correction: A long-standing logical error in the function that estimates the cost and benefit of hypothetical indexes has been fixed, improving the accuracy of performance predictions.
- relid crash fix: The release resolves improper relation ID handling within hypothetical indexes that could cause the PostgreSQL backend to crash during index evaluation operations.
- Version compatibility: HypoPG 1.4.5 maintains backward compatibility with PostgreSQL 9.2 and all subsequent releases, requiring no migration steps for existing installations.
- Maintenance scope: This is a pure bug-fix release with no new features, configuration options, or SQL-callable functions added.
Why it matters
Database administrators who rely on HypoPG to validate indexing strategies before committing storage and write-amplification costs gain more reliable tooling. The crash fix removes a potential production hazard when running hypothetical index analysis on complex schemas, while the estimation correction restores trust in the extension's cost modeling for query optimization workflows.
Original reference: www.postgresql.org →