In SQL Server 2008, in DMV sys.dm_db_index_phsicial_stats, what does compressed_page_count mean in comparision with page_count In SQL Server 2008, DMV sys.dm_db_index_physical_stats, what does compressed_page_count mean in comparison with page_count. I have a table with the following info:

Object_id     Index_type_desc      avg_frag_in_percent    page_count     compressed_page_count        avg_page_space_used_in_percent       avg_record_size_in_bytes
5464654        CLUSTERED INDEX         0                    140992          1410                                        99.24                        111.2
4465464        NONCLUSTERED INDEX      0                    52532           526                                         99.69                         32.2


Does it mean, that the table has 140992 pages, but after compression it is brought down to 1410 pages or something else?


  [BOL says:] MSDN
  compressed_page_count: The number of compressed pages.
The clustered index has 140992 pages, from which only 1410 are page compressed. Page compression is attempted only when it fills up, see When Page Compression Occurs:


  When a new table is created that has page compression, no compression
  occurs. However, the metadata for the table indicates that page
  compression should be used. As data is added to the first data page,
  data is row-compressed. Because the page is not full, no benefit is
  gained from page compression. When the page is full, the next row to
  be added initiates the page compression operation. The whole page is
  reviewed; each column is evaluated for prefix compression, and then
  all columns are evaluated for dictionary compression. If page
  compression has created enough room on the page for an additional row,
  the row is added, and the data is both row- and page-compressed. If
  the space gained by page compression minus the space that is required
  for the CI structure is not significant, page compression is not used
  for that page. Future rows either fit onto the new page or, if they do
  not fit, a new page is added to the table. Similar to the first page,
  the new page is not at first page-compressed.


It seems that in your case very few pages got compressed. Note that you still benefit from row compression.