Attributes

Overview

Attributes are metadata tags applied to a list or column that tell kdb+ about its structure. When kdb+ sees an attribute, it can replace a linear scan with a faster algorithm — binary search, a hash lookup, or an index — without any change to the query itself. Applied correctly, they are one of the most effective performance tools in kdb+.

There are four attributes: sorted (`s#), unique (`u#), parted (`p#), and grouped (`g#). Each makes a different structural promise about the data and is appropriate in different contexts.

How This Topic Is Organised

First, the four attributes — what each one promises, how it is stored internally, and the performance mechanism it enables — The Four Attributes.

Then attributes in the tick architecture — why the RDB uses `g# on sym, why the HDB uses `p#, which attributes aj needs, and why p# is not suitable for the RDB — Attributes in the Tick Architecture.

Then performance and troubleshooting — how appending data can silently remove attributes, how to re-apply attributes after an HDB append, and how to diagnose slow in-memory and historical queries — Performance & Troubleshooting.

Then the concrete performance numbers — benchmarks from KX's columnar database white paper showing how each attribute affects query time and workspace, the \ts profiling tool, memory overhead by attribute type, and the ~1 million row point where u# starts to matter — Performance Benchmarks.

Finally the gotchas and edge cases — s# can be applied in place while the others need reassignment, only the first where constraint can use an attribute, joins and modifications remove attributes, step-function dictionaries, and s# applied to tables — Gotchas & Edge Cases.

Key Things to Know

The most important rule: the attribute must match the actual structure of the data. Applying s# to unsorted data fails with 's-fail; applying u# to data with duplicates, or p# to data whose equal values are not contiguous, fails with 'u-fail. Check with attr after applying.

The second most important rule: changing data can silently remove attributes. After any append to an HDB partition, re-check and re-apply p# before serving queries. In the RDB, g# is used because it is kept through continuous appends in any order.

The third most important rule: only the first constraint in a where clause can use an attribute. Later constraints are evaluated only on the rows that passed the earlier ones, so a column's attribute cannot help them. Put the constraint on the attributed column first (and, in a partitioned database, the partition column before everything else).