Change theme
Help
Press space for more information.
Show links for this issue (Shortcut: i, l)
Copy issue ID
Previous Issue (Shortcut: k)
Next Issue (Shortcut: j)
Sign in to use full features.
Vote: I am impacted
Notification menu
Refresh (Shortcut: Shift+r)
Go home (Shortcut: u)
Pending code changes (auto-populated)
View issue level access limits(Press Alt + Right arrow for more information)
Request for new functionality
View staffing
Description
Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.
What you would like to accomplish:
1) Investigate pruning performance with 100M file case. There is a known bottle neck with CMETA based pruning for external tables - the pruning is single threaded.
2) How does Trino support pruning for such large tables?
How this might work: The customer complained that even with a valid cache and partition pruning on the 100M file case, the customer finds query performance to be ~2 minutes, which is slower than using queries for similar table sizes (e.g. 100M+ files) without caching. So they asked why is Trino faster?
If applicable, reasons why alternative solutions are not sufficient:
Other information (workarounds you have tried, documentation consulted, etc):