Curt,

It was Netezza’s marketing group that opted for euphony over precision in labeling the block of logic performing decompression the “Compress Engine”. Notice how they carefully avoided calling it the “Compression Engine” or the “Decompression Engine”. The ensuing confusion was entirely predictable.

Netezza has always focused on scan-mostly activities. Thus it makes sense to invest FPGA engineers and gates in decompression. All the more so since decompression is deterministic — the bit stream expresses exactly what to do.

By contrast, compression is a much more challenging activity. Nearly any compression scheme presents redundant encoding opportunities. Sometimes making good choices requires look-ahead or at least back-patching. That sort of stuff is _really_ hard to implement in an FPGA. Netezza’s experience is that with careful implementation software compression can be implemented with minimal impact on CPU utilization.

Finally, let me close with an historical analogy from the world of computer graphics. The earliest graphical workstations had only a bit mapped frame buffer manipulated in a high level language (e.g. Xerox Alto + Smalltalk). The drive for increasing graphics performance lead successively to carefully crafted assembly language (e.g. Mac toolkit), pixel interpolation hardware, and ultimately full graphics pipelines of ever increasing complexity. Yet today does anyone argue against “proprietary” graphics hardware? Could it be that hardware support for processing database fields is as inevitable as hardware support for generating pixels?

/john

For example, our (xtremedata) dbX appliance replaces a CPU with our “SQL In Silicon” (FPGA) in-socket accelerator, and removes 90 watts per server by doing this. This is 16 nodes * 90 Watts per rack or 1.44KWatts per rack.

Thus, I’m sure the TwinFin S-Blade sees a real power/cooling benefit over a dual-socket CPU-only blade.