GitHub user tanishqgandhi1908 added a comment to the discussion: Design: interactive grid for the operator result pane
Thanks @mengw15, I agree that full-result backend filtering/search/sort has concerns, especially for large outputs. Iceberg predicate pushdown can help in some cases, but because operator results are written in arrival order, pruning may be weak. To make the feature safer and easier to review, I would like to split the work into phases. 1. First PR: interactive result grid UI only - Replace the current table with ag-grid - improve column virtualization, resizing, reordering, hide/show columns - Row inspector docks inline below the grid (replaces today's popup modal). - Pagination with auto-fit page size - Sort and per-column filter wired but page-local — they operate on rows currently in ag-grid's cache, with a visible "view only" banner so they don't read as workflow-level filters. (Or hide the UI entirely in PR 1 if the team prefers — open to either.) - Bottom-docked result panel (replaces the draggable floating popup). 2. Follow-up design: full-result querying - add benchmarks on realistic result sizes - add timeout / cancellation behavior - add scan/sort limits - clearly mark filters as “view only” - possibly explicit Apply behavior instead of querying on every keystroke To answer on above points- 1. Cost, latency, and cancellation - You are right that sort, row search, contains, and endsWith can be expensive on large outputs. Sort is especially risky and it has to happen in backend memory. 2. View vs dataflow semantics - Yes, this is intended to affect only the result-pane view. The downstream operator still receives the full operator output. I can make this explicit in the UI. I will label these controls as view/search controls, not workflow transformations, and add a visible view only banner near active filters so users do not confuse this with the Filter / Selection operators. 3. Persistence of query state - Not persisted as workflow semantics. At most we keep per-operator query state transiently in the browser session, so switching away and back restores the same view. A page reload starts from the unfiltered result. 4. Relationship with Filter / Selection operators - I see the line as: result-pane filters/search/sort: temporary exploration and debugging; Filter / Selection operators: persistent workflow transformations whose outputs flow downstream. Does this split and details sound reasonable? If yes, I can narrow the implementation to the interactive result grid first and leave backend full-result filtering/search/sort for a separate design and follow-up PR. Or open to any other suggestions. Thanks GitHub link: https://github.com/apache/texera/discussions/5395#discussioncomment-17291802 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
