Add $snapshot_id hidden column to Iceberg connector

[tdcmeehan]

Expected Behavior or Use Case

Add a $snapshot_id hidden column to Iceberg tables that exposes the snapshot ID as a column, enabling snapshot-based filtering.

  -- Filter by specific snapshot
  SELECT * FROM my_table WHERE "$snapshot_id" = 1234567890;

  -- Join with snapshot metadata
  SELECT t.*, s.committed_at
  FROM my_table t
  JOIN "my_table$snapshots" s ON t."$snapshot_id" = s.snapshot_id;

Presto Component, Service, or Connector

Iceberg connector

Possible Implementation

Follow the existing pattern for $path:

1. Add SNAPSHOT_ID to IcebergMetadataColumn
2. Populate in IcebergPageSourceProvider from split's snapshot ID
3. Implement as file-level metadata column (constant per split)
4. (Not done for $path) Push down in IcebergMetadata#getTableLayoutForConstraint for predicates like $snapshot_id >= X (this maps to FOR VERSION AS OF (X)). Improve further as needed.

Example Screenshots (if appropriate):

Context

This would be a hidden column which is not documented, as it could lead to strange results if a user supplied it. It would be used by an optimizer to enable optimization techniques which can leverage Iceberg's incremental scans--by creating a virtual column, a predicate can be created on the column.

[steveburnett]

"This would be a hidden column which is not documented, as it could lead to strange results if a user supplied it. It would be used by an optimizer to enable optimization techniques which can leverage Iceberg's incremental scans--by creating a virtual column, a predicate can be created on the column."

I could see value in documenting the existence of this $snapshot_id hidden column in the context of optimizer development, with a caution that this should never be user-generated. Otherwise, how do people know it's there to enhance optimization techniques?

[tdcmeehan]

@steveburnett instead of "no documentation", what if we considered different documentation, for example documentation in the code. My worry about putting it in the user documentation is we would almost never want a user to actually utilize the column, we'd want to keep it only to internal usage.

[steveburnett]

Maybe? I agree about putting it in the general user documentation not being the best. I was thinking perhaps the Developers Guide part of the Presto docs.

[tdcmeehan]

@steveburnett the trouble there is that's a general guide for plugins (with the aim being for developers writing new plugins), but this would be for a particular specific existing plugin.