You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The block is shared (e.g. DictionaryBlock or think of broadcast join) and the same block is used for multiple key lookups (Same key or different key).
The block is not shared, but the query is trying to look at multiple keys in the same map.
But there are cases, where only one key is looked at in the map. In this case computing hash table takes more time than doing a scan.
A simple example to demonstrate this is
SELECT ELEMENT_AT(Map, key) from Table
Today this query will compute hash tables in the Map and will do a single key lookup.
Should the Map.elementAt switched to heuristics based (similar to JIT profile guided optimization) ? First time always do a simple scan, but if multiple lookups are happening in the map, switch to hash tables ?
The text was updated successfully, but these errors were encountered:
Map's elementAt implementation always computes hash table. https://github.com/prestodb/presto/blob/master/presto-common/src/main/java/com/facebook/presto/common/block/SingleMapBlock.java#L263
This saves CPU for 2 cases.
But there are cases, where only one key is looked at in the map. In this case computing hash table takes more time than doing a scan.
A simple example to demonstrate this is
SELECT ELEMENT_AT(Map, key) from Table
Today this query will compute hash tables in the Map and will do a single key lookup.
Should the Map.elementAt switched to heuristics based (similar to JIT profile guided optimization) ? First time always do a simple scan, but if multiple lookups are happening in the map, switch to hash tables ?
The text was updated successfully, but these errors were encountered: