Details
-
Type:
Sub-Task
-
Status: Open (View Workflow)
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: Icebox
-
Component/s: Storage Manager
-
Labels:None
Description
This has fallen through the cracks. I do not believe we ever got around to implementing size reporting for SM. IIRC, the way it is done by other IDBDataFiles when a table is compressed, is to load all of the data, decompress all of the data, and sum up the size of the fully decompressed data. That's awful for tables on a local disk, and would be even more awful to implement it that way for S3-backed tables.
Ideally, for this ticket we would redesign that for SM and non-SM tables. Maybe we can return a size estimate based on extentmap data instead. If it needs to be a precise value (not sure how important that is), maybe we add an extra field to EM data for this. Alternatively, we can store the uncompressed size of a compressed file in the file header to reduce the amount of data to load and avoid extra steps. Many easy options for this one.