Map
You use maps to store key-value pairs where you have too many different keys to create separate fields. Hamelin's map type matches SQL's design - it's a homogeneous structure where all keys have the same type and all values have the same type.
When to use maps
You should use maps rarely. Before using a map, consider whether you could:
- Factor subset key spaces into separate tables
- Leave the data as a JSON string and parse only commonly needed values into fields
You use maps only when you have a high cardinality key space that can't be handled with these alternatives.
Creating maps
You construct maps using the map() function, which has two overloaded forms.
Map literals
You create a map by listing key-value pairs directly:
SET config = map(
'timeout': 30,
'retries': 3,
'debug': false
)
From key and value arrays
You build a map from separate arrays of keys and values:
SET field_names = ['user_id', 'email', 'created_at']
SET field_values = [12345, '[email protected]', '2024-01-15']
SET user_data = map(field_names, field_values)
Empty maps
You create an empty map using the function without arguments:
SET empty_config = map()
Type homogeneity
Maps must be homogeneous - all values must have the same type. This example will generate an error:
// ERROR: mixing integer and string values
SET broken_map = map(
'count': 42,
'name': 'example'
)
Accessing map values
You use bracket notation to retrieve values by key:
FROM events
| SET metadata = map('source': 'api', 'version': 2)
| SELECT event_source = metadata['source']
Map storage
The underlying engine stores each map as a pair of related columns - one for keys and one for values. Row positions in each column relate the keys to their values.
Performance considerations
Unlike structs, which add overhead by creating a column per field, maps have minimal impact on table width (only two columns). However, you pay the cost of key values being actual data rather than column names, even though they're dictionary encoded.