-
Notifications
You must be signed in to change notification settings - Fork 3k
Join reads full table when I am only interested in a subset #23442
Replies: 1 comment · 4 replies
-
Trino does have a dynamic filter operation which tends to pass the unique values of |
Beta Was this translation helpful? Give feedback.
All reactions
-
This is the query plan (I've redacted it a bit to protect the actual tables):
|
Beta Was this translation helpful? Give feedback.
All reactions
-
Can you provide the output of EXPLAIN ANALYZE VERBOSE in the above case ? |
Beta Was this translation helpful? Give feedback.
All reactions
-
I found out a bit more: the size of the query_table influences how the huge_table is read, which is something I did not expect. Slow query:
Fast query
|
Beta Was this translation helpful? Give feedback.
All reactions
-
Based on this, I found this partial solution: I do not exactly understand why the original query does not work. It seems that a dynamic filter is created, but that the read of huge_table is placed in a fragment that cannot benefit from it. This query basically does the same thing. The second read from query_table6 results in a new dynamic filter and that is used to filter huge_table. And that dynamic filter should be exactly the same as the dynamic filter used in the original query. So why is the huge_table read placed in a separate fragment?
|
Beta Was this translation helpful? Give feedback.
All reactions
This discussion was converted from issue #23434 on September 16, 2024 11:16.
-
I have a large table (150M rows) that contains a column with an array of data (20KB of data). The total is 3TB of data. I am using pyiceberg tables.
I want to read a subset of this table, based on the results of a query on a different table:
SELECT * FROM huge_table ht INNER JOIN query_table qt ON ht.key = qt.key WHERE qt.something = 'X'
The problem is that the query plan for this results in a list of keys that are then joined with the huge table. This causes Trino to load the entire huge_table (3TB) and then filter out the unwanted data, which is rather slow.
If I manually split the queries:
SELECT key FROM query_table qt WHERE qt.something = 'X'
SELECT * FROM huge_table ht WHERE ht.key in ()
the read only reads the part of the table I want, a much faster operation ( is pushed down to the ScanFilter operation). However, the eventually should support around 1M keys, so this does not seem to be a proper solution.
I have tried rewriting the query in several ways, but Trino always resolves it to a join (which is fair enough, the operation is essentially a join). But is there a way to convince Trino that I really want the filter keys to be pushed down to the read operation (ScanFilter in the execution plan)?
Beta Was this translation helpful? Give feedback.
All reactions