@Rocky is there a way to know how much space bitmap / bloom filter index take?

Currently, StarRocks does not provide a single, direct SQL command (like

SHOW INDEX SIZE

) to view the exact disk storage used specifically by bitmap or bloom filter indexes on a per-table basis. However, you can estimate this or find related metrics using the following methods: 1. Estimate via Column Storage Functions Since v3.1, StarRocks provides metadata functions to check the storage size of specific columns. Because bitmap and bloom filter indexes are stored within the same segment files as their corresponding columns, checking the column's total size is the closest way to see its storage footprint.

sql
-- Get compressed on-disk size of a column
SELECT column_compressed_size(column_name) 
FROM table_name [_META_];

-- Get uncompressed size
SELECT column_size(column_name) 
FROM table_name [_META_];

Note: This includes both the column data and its associated built-in indexes (like ZoneMap/Ordinal), but manually created indexes (Bitmap/Bloom Filter) also contribute to the overall storage weight of that column. 2. View Memory Consumption (BE Metrics) If you are interested in how much memory these indexes occupy (as they are loaded into the Page Cache for query acceleration), you can check the Backend (BE) metrics. Look for these specific items: * `bitmap_index_mem_bytes`: Memory used by bitmap indexes. * `bloom_filter_index_mem_bytes`: Memory used by Bloom filter indexes. You can access these by visiting the BE's metrics endpoint:

http://<BE_IP>:<BE_HTTP_PORT>/metrics

. 3. Check Tablet Metadata (Advanced) StarRocks stores index size information in the metadata of each Rowset. You can inspect this for a specific tablet, though it requires multiple steps and is usually intended for debugging: 1. Run

SHOW TABLETS FROM <table_name>;

to get a Tablet ID. 2. Use the

check_tablet_segment_size

or similar tools/commands (like

SHOW PROC '/dbs/<db_id>/<table_id>/partitions/<part_id>/index/<index_id>/<tablet_id>';

) to see tablet details. 3. In some internal metadata views (like GitHub discussions regarding

index_disk_size

), there is a distinction between

data_disk_size

and

index_disk_size

, but this is not currently exposed as a standard column in

information_schema

. Key Takeaways * Space Efficiency: Bloom filter indexes are generally very space-efficient (probabilistic structures), while Bitmap indexes can grow significantly if applied to high-cardinality columns. * Inverted Indexes: In newer versions (v3.3+), if you use Inverted Indexes, you might see separate files or more detailed metrics, but for traditional StarRocks Bitmap/Bloom Filter indexes, they are embedded within the segment

.dat

files. If you are seeing unexpected disk growth after adding an index, the best way to verify the impact is to compare the

column_compressed_size

of that column before and after the

ALTER TABLE

operation (which runs as an asynchronous job). References • administration/management/monitoring/metrics.md • table_design/indexes/Bloomfilter_index.md • knowledge/usage/best-practice.md