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.