Guten Tag Richard Wesley,

> On 21 Jan 2009, at 09:25, Dmitry Yemanov wrote:

>> The entire record is RL compressed as a whole. And the record has
>> has a
>> fixed format, i.e. every column is represented with its maximum
>> length.

> This sounds like the contents of each record is compressed, BUT each
> record still takes a fixed (maximal) amount of space on disk? That
> can't be right - you add no disk read efficiency but still have to
> sacrifice CPU cycles to read the data. What am I missing?

> One of the reasons that I ask is I have just finished reading "Read-
> Optimized Databases, In Depth" by Allison L. Holloway and David J.
> DeWitt, SIGMOD 2008, which claims that using row level compression can
> give a row-oriented RDBMS comparable I/O performance to a column-
> oriented one with row compression (better in some cases involving
> table scans and wide result tuples). If FB is using compression to
> fit more rows onto database pages to reduce disk reads, that would be
> awesome, but your description does not sound like that is what is
> going on.

from what i understand the In-Memory Record is Full Length
then it is compressed and the compressed record is stored on disk

so for the original questions Varchar 2000
has an in memory size of 2002 bytes (asuming single byte charset)
(2000 chars plus 2 bytes for the length )

which is then compressed to a record of
Best Case 32 bytes (16 Rl-Fields of 2 bytes each)
Worst Case 2018 bytes (2002 bytes User data plus 16 RLC Flags every 127
Bytes indication that the following data is not compressed)




--
Mit freundlichen Grüssen
Hannes Streicher mailto:HStreicher@...