Re: Any risk in increasing BLCKSZ to get larger tuples?

Steve Wolfe wrote:
>
> > 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.
>

It isn't the system bus, its the hardware of the hard disk. In general
hardware costs are much bigger than a few cpu cycles (especially as cpu
cycles are increasing with Moore's law and hardware access times
aren't), but that isn't always the case (like in drivespace in Windows).

Recently I was doing performance tuning on my application where I was
adding a bunch of users to the system. i was making 6 db calls per user
added. I assumed that the cpu costs of what I was doing was the
limiting factor, but the cpu usage was only at like %20. Reducing the
db calls to 4 meant a big increase in performance, streamlining the code
was negligble.

That's why I said for some cases automatic compression makes sense, for
others it doesn't.

--
Joseph Shraibman
jks(at)selectacast(dot)net
Increase signal to noise ratio. http://www.targabot.com