SSTS_STORAGE

The SSTS_STORAGE table provides access to SST (Sorted String Table) file information listed directly from the storage layer. This table shows raw file metadata from object storage, which may include files that are not yet reflected in the manifest or files that have been orphaned.

NOTE

This table is not available on GreptimeCloud.

USE INFORMATION_SCHEMA;
DESC SSTS_STORAGE;

The output is as follows:

+------------------+----------------------+-----+------+---------+---------------+
| Column           | Type                 | Key | Null | Default | Semantic Type |
+------------------+----------------------+-----+------+---------+---------------+
| file_path        | String               |     | NO   |         | FIELD         |
| file_size        | UInt64               |     | YES  |         | FIELD         |
| last_modified_ms | TimestampMillisecond |     | YES  |         | FIELD         |
| node_id          | UInt64               |     | YES  |         | FIELD         |
+------------------+----------------------+-----+------+---------+---------------+

Fields in the SSTS_STORAGE table are described as follows:

• file_path: The full path to the file in object storage.
• file_size: The size of the file in bytes (if available from storage).
• last_modified_ms: The last modified time in milliseconds since epoch (if available from storage).
• node_id: The ID of the datanode where the file is located.

Use Cases

The SSTS_STORAGE table is useful for:

• Storage verification: Compare files in storage against the manifest to detect orphaned files or inconsistencies.
• Storage debugging: Identify files that exist in storage but may not be properly tracked in the manifest.
• Cleanup operations: Find and remove orphaned SST files that are no longer referenced.
• Storage auditing: Get a complete view of all SST files in the storage layer.

Examples

Query all SST files in storage:

SELECT * FROM INFORMATION_SCHEMA.SSTS_STORAGE;

Find files in storage that are not in the manifest (potential orphaned files):

SELECT s.file_path, s.file_size, s.last_modified_ms
FROM INFORMATION_SCHEMA.SSTS_STORAGE s
LEFT JOIN INFORMATION_SCHEMA.SSTS_MANIFEST m ON s.file_path = m.file_path
WHERE m.file_path IS NULL;

Find the largest SST files in storage:

SELECT file_path, file_size
FROM INFORMATION_SCHEMA.SSTS_STORAGE
WHERE file_size IS NOT NULL
ORDER BY file_size DESC
LIMIT 10;

Calculate total storage usage by SST files:

SELECT COUNT(*) as file_count, SUM(file_size) as total_size
FROM INFORMATION_SCHEMA.SSTS_STORAGE
WHERE file_size IS NOT NULL;

Output example:

mysql> SELECT * FROM INFORMATION_SCHEMA.SSTS_STORAGE LIMIT 1\G;
*************************** 1. row ***************************
       file_path: data/greptime/public/1024/4398046511104_0/01234567-89ab-cdef-0123-456789abcdef.parquet
       file_size: 1234
last_modified_ms: 2025-01-01 00:00:00.000
         node_id: 0
1 row in set (0.02 sec)

Differences from SSTS_MANIFEST

Aspect	SSTS_MANIFEST	SSTS_STORAGE
Data Source	Manifest metadata	Storage layer directly
Information	Detailed SST metadata (rows, time ranges, etc.)	Basic file metadata only
File Coverage	Only files tracked in manifest	All files in storage
Use Case	Query SST metadata for analysis	Verify storage, find orphaned files
Performance	Fast (reads from manifest)	Slower (scans storage)