InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 19 May 2013 08:54:45 GMT20http://www.sqlservercentral.com/Forums/Topic1261172-263-1.aspxCompression to save disk space is of dubious value unless it saves IO.With technologies such as Fusion-IO and SSDs where you are talking about literally thousands of times that of mechanical disks IO performance does compression offer still offer benefits?Where does the bottleneck shift once mechanical disk IO is mitigated?Tue, 06 Mar 2012 11:26:37 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic1261172-263-1.aspxTDE occurs when the pages are written to disk or read from disk. This means that TDE has little to no impact on page or row compression. You are correct about compression at the file level though.Mon, 05 Mar 2012 12:36:42 GMTCharles Hearnhttp://www.sqlservercentral.com/Forums/Topic1261172-263-1.aspxJust remember that a database encrypted with TDE does not compress all that much.:-DMon, 05 Mar 2012 07:43:51 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1261172-263-1.aspxHave a bunch of MS Dynamics GP databases. The tables typically are substantially de-normalised (very "wide" tables of partially redundant data), have long fixed length character columns, and large numbers of decimal columns containing zeros. The databases and all their contained tables (some 1000 tables in a typical GP database) compress excellently using row compression; we haven't implemented page compression. In the large number of tables it appeared difficult to select appropriate candidates; it seemed easier to row compress all (except tables with a very low number of rows) and uncompress the exceptions if and when we found them. Have found no noticeably poor candidates as yet. In fairness to MS the table design is probably a legacy from the earlier multi-database support In terms of CPU usage I am assuming that SELECTs with a high number of logical reads (in the hundereds of thousands of rows) should show high CPU when compressed. The effect does not appear noticeable, and the server in any case currently has horsepower to spare. Any effect is dwarfed by other CPU effects we may have from custom codeSince we are currently blessed with both sufficient RAM to contain the entire set of databases (nearly zero read IO from the smaller databases), and more recently some really fast write IO, our performance experience is a trifle difficult to compare Tony TSun, 04 Mar 2012 02:25:47 GMTtony.turnerhttp://www.sqlservercentral.com/Forums/Topic1261172-263-1.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Editorial/88933/">Data Compression Double Take</A>[/B]Sat, 03 Mar 2012 11:48:14 GMTTony Davis