Assuming no qualification is done, just a simple select * or select
The system has to access one container from each partition, step through them in sequence (executing any algorithm necessary for identifying
the right value from the in-use compression algorithms), take the row position value from each container and copy them in the correct sequence
into an output row form and place that row where it needs to go (probably into a spool for retrieval or further processing). This has a cost.
This processing is similar for all columnar systems and leads to the well documented tradeoff curves for columnar retrieval. Dependent on
column sizes and types of course but for all columnar implementations there is a breakeven point somewhere in the 10-25% range. Accessing a
greater percent of the columns is more efficient if the data is stored and retrieved in row form. Lower percent of columns accessed, columnar form
wins.
If there is qualification, then we qualify in the most selective column(s) first, then access the aligned values from the other columns and
this can change the equation if it is highly selective. Then the efficiency improvement on the selection exceeds the efficiency loss on the
assembly of the result rows.
These tradeoffs are why we have implemented columnar as an option at the table level in Teradata so that people can balance the tradeoffs for
each table based on the table itself and how the workloads most typically access the data in the table. Narrow tables or tables where most columns
are always accessed may well work better in row form while a wide table from which users typically access a small subset of the columns will work
better in columnar form. And opportunities to further optimize with alternate structure in a single table join index for workloads that do
both.
