> In some cases yes, in some no. Simple text should compress/decompress > quickly and the cpu time wasted is made up for by less hardware access > time and smaller db files. If you have a huge database the smaller db > files could be critical. Hmm... that doesn't seem quite right to me. Whether it is compressed or not, the same amount of final data has to move across the system bus to the CPU for processing. It's the difference of (A) moving a large amount of data to the CPU and processing it, or (B) moving a small amount of data to the CPU, use the CPU cycles to turn it into the large set (as large as in (A)), then processing it. I could be wrong, though. steve
- [GENERAL] Any risk in increasing BLCKSZ to get larger tup... Philip Hallstrom
- Re: [GENERAL] Any risk in increasing BLCKSZ to get l... Neil Conway
- [GENERAL] to_char function Yohans Mendoza
- Re: [GENERAL] Any risk in increasing BLCKSZ to get l... Tom Lane
- Re: [GENERAL] Any risk in increasing BLCKSZ to g... Joseph Shraibman
- Re: [GENERAL] Any risk in increasing BLCKSZ ... Neil Conway
- Re: [GENERAL] Any risk in increasing BLCKSZ ... Steve Wolfe
- Re: [GENERAL] Any risk in increasing BLC... Joseph Shraibman
- Re: [GENERAL] Any risk in increasin... Steve Wolfe
- Re: [GENERAL] Any risk in increasing BLCKSZ ... Tom Lane
- Re: [GENERAL] Any risk in increasing BLC... Joseph Shraibman
- Re: [GENERAL] Any risk in increasin... Philip Hallstrom