AI / Apache Paimon Interview questions
How can you optimize query performance using the read-optimized system table?
When a downstream query can tolerate slightly stale data — as of the last full compaction rather than the absolute latest commit — querying my_table$ro instead of the base table skips the merge-at-read-time cost entirely, since it only touches files that are already fully merged.
-- Slower: merges across all sorted runs at query time SELECT COUNT(*) FROM my_table WHERE status = 'active'; -- Faster: only reads already-compacted, top-level files SELECT COUNT(*) FROM my_table$ro WHERE status = 'active';
This is a good fit for dashboards and periodic batch reports refreshed on a schedule roughly aligned with your compaction cadence, where the small freshness gap doesn't matter but query latency does. It's a poor fit for anything needing guaranteed up-to-the-second correctness, or point-lookups on very recently upserted keys that haven't been through a full compaction yet.
Querying $ro instead of the base table trades away:
$ro is a poor fit for:
More Related questions...
