| Subject | Re: [firebird-support] Table structure for efficient storage |
|---|---|
| Author | Daniel L. Miller |
| Post date | 2010-06-16T18:57:05Z |
On 06/16/2010 09:28 AM, Ann W. Harrison wrote:
achieves little or no gains - or in some cases costs to much in terms of
productivity. But the way my brain is wired I gotta ask anyway...
My "thinking" (gotta put that in quotes, after all, I'm sitting down at
the moment) is that greater compression results in fewer disk reads, and
smaller disk cache consumption - although there might be a tradeoff in
de-compression processing. But again, my "thinking" is that if a
relatively minor re-organization of table structure results in more
efficient storage, then retrieval speeds should be sped up as well.
--
Daniel
> Daniel L. Miller wrote:No argument whatsoever - and typically some of this "optimization"
>
>> Does the order/sequence of columns in a table make a difference in
>> storage? I.e., is a table of CHAR(1), CHAR(1), CHAR(1), CHAR(1),
>> SMALLINT, VARCHAR(50) stored differently than CHAR(1), SMALLINT,
>> CHAR(1), VARCHAR(50), CHAR(1), CHAR(1)?
>>
> Yes it is, but it's not worth worrying about. There are two
> considerations: the number of pad bytes introduced to maintain
> field alignment in the record buffer and the effect of run-length
> compression.
>
> [..]
>
> Disks are cheap.
>
>
achieves little or no gains - or in some cases costs to much in terms of
productivity. But the way my brain is wired I gotta ask anyway...
My "thinking" (gotta put that in quotes, after all, I'm sitting down at
the moment) is that greater compression results in fewer disk reads, and
smaller disk cache consumption - although there might be a tradeoff in
de-compression processing. But again, my "thinking" is that if a
relatively minor re-organization of table structure results in more
efficient storage, then retrieval speeds should be sped up as well.
--
Daniel