Hi Shangqing And thank you for driving this. I have already seen requests for a Trino connector, so this is something very much needed that will help fluss open up to more engines. It's a genuinely well-scoped proposal and provides a solid foundation.
Some things that come to mind that might be worth looking into: *1. The bounded log split*. The FIP describes a Log split as (bucket, startOffset, stoppingOffset) as if a bounded log read exists, but it doesn't: createBatchScanner on a log table is row-limit bounded, not offset-range bounded. Today you'd build this on the unbounded LogScanner plus Admin.listOffsets(LATEST) to capture stop points and what the Flink connector already does. I'd suggest extracting that into a small engine-neutral "bounded-offset log scanner" in fluss-client (Spark and other engines would benefit too). *2. "Fail rather than silently skip" on log retention needs to be a verified contract.* The default log scanner may auto-reset to the earliest offset when a planned offset has expired, which would quietly violate the guarantee the FIP makes. Worth confirming this behavior and adding some tests to verify this. *3. Bucket pruning needs a small stable helper.* The bucketing function is reusable, but turning predicate values into a bucket id requires the exact canonical key encoding, and those pieces are currently internal. A tiny engine-neutral "key values → bucket id" utility would let the connector prune correctly without duplicating anything. That's the second (and only other) new API I'd call out. *4. PK Table Reads* For the primary key table reads, it might be worth using the newly added api https://cwiki.apache.org/confluence/spaces/FLUSS/pages/386272150/FIP-17+Support+Full+KV+Scan+for+Primary+Key+Tables I hope these help a bit.. Let me know your thoughts. Best, Giannis On Wed, Sep 2, 2026 at 7:29 AM Shangqing Yang <[email protected]> wrote: > Hi Fluss community, > > I’d like to start a discussion about adding a native, read-only Trino > connector for Apache Fluss. > > There has already been previous exploration of Trino integration in > FIP-18, #1810, PR #1923, and the related mailing-list discussion. Those > efforts provide valuable prior work, but they also covered several > relatively independent topics at once, including native Fluss reads, > multi-version Trino support, Lakehouse Union Read, Lakehouse readers, and > additional pushdowns. > > For this proposal, I’d like to narrow the scope and first establish a > clean native Trino-to-Fluss read path. > > The initial scope includes: > > metadata discovery and type mapping; > bounded reads of non-Lakehouse Log Tables; > current-state reads of non-Lakehouse Primary Key Tables; > projection and predicate-based scan optimizations; > partition and bucket pruning where applicable; > primary-key lookup optimization; > an explicit Trino compatibility and build-isolation policy. > > Lakehouse Union Read, Lakehouse format readers, writes/DDL, and changes to > Trino core are explicitly out of scope for this FIP. I think Union Read is > an important follow-up topic, and I’d be happy to drive a separate proposal > for it after the native connector is established. > > Since I don’t currently have permission to create the FIP page on > Confluence, I’ve prepared the proposal as a Google Doc using FIP-XXX as the > temporary identifier: > > Design doc: > https://docs.google.com/document/d/1mY-PN8KY1cJSD9YzISuL14A6rEIH1Htj9l99XrLmPk0 > > Issue: https://github.com/apache/fluss/issues/4197 > > I’d especially appreciate feedback on the proposed scope, the Log Table > and Primary Key Table read semantics, and the Fluss Client API boundary. > > Prior work: > > FIP-18: Fluss Trino Engine Support > #1810 > PR #1923 > > Feedback and suggestions are very welcome. > > Thanks, > Shangqing
