Archives of the TeradataForum

Message Posted: Wed, 28 Aug 2002 @ 23:27:52 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

In Teradata the compression is actually a bit field lookup. The bit field is stored in the row header. The lookup table for each column is stored in the table header. So decompression is very low overhead in Teradata. When we create the evaluation code for a row, it's just simple pointer arithmetic to find a field value in the table header vs. actually in the row. Everything is in memory by that time anyway. While there is certainly some small computation overhead to locating the field value in the table header rather than the row, customer results have shown that this is more than compensated for by the savings in computation introduced by doing less total I/O's. We typically see around 5% total savings in cpu resource immediately after compression has been introduced and before additional data has been loaded.

In terms of keeping the compression on spool, it seems pretty straightforward to me - a column in spool would inherit its compression characteristics from its parent table. I suppose it gets a bit complicated when the column in spool is one on which there are equijoin conditions - i.e., the column has two parent tables. In that case a design decision must be made - perhaps pick the compression characteristics of one of the parent tables for that column.

Mark Morris
Teradata Architecture

	<Prev	Next>		<<First	<Prev	Next>	Last>>