September 23, 2020 at 4:49 pm
Hi
This probably a silly question but.....
If I query the size of a table and it shows 20 gigs in size, when I do a select * from that table from another server will I bring back 20 gigs over the network?
thanks in advance
September 23, 2020 at 9:00 pm
More or less, eventually, depending on whether you're looking at raw or compressed data size... And assuming your client doesn't time out or crash from an out-of-memory condition.
Once client-side, the data may balloon significantly larger in a client like SSMS which formats the data.
September 24, 2020 at 12:52 am
The table size usually includes the size of all indexes created on the table.
for SELECT * query you need to know the size of the index with indid=1 or 0.
_____________
Code for TallyGenerator
September 24, 2020 at 1:20 am
Thanks can you explain the index = 1 or 0 please ?
September 24, 2020 at 2:31 am
Hi
This probably a silly question but.....
If I query the size of a table and it shows 20 gigs in size, when I do a select * from that table from another server will I bring back 20 gigs over the network?
thanks in advance
You've not explained what you used to "query the size" of the table. To Sergiy's good point, you might be including all of the indexes, which could be as much or more than the data in the "table". I have table in quotes because if it's a HEAP, you need to look at Index 0 (which is the HEAP itself). If it has a Clustered index, you need to check the size of Index 1, which is the Clustered Index and that's where the data in a "clustered table" lives.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 28, 2020 at 10:25 am
You can get the information from this select-statement. It shows the size of the table and the size of indexes in 8KB pages.
SELECTi.name,
ps.index_type_desc,
ps.index_id,
ps.index_level,
ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID('databasename'), OBJECT_ID('tablename'), NULL, NULL, 'DETAILED') AS ps
INNER JOIN sys.indexes AS i
ON ps.object_id = i.object_id AND ps.index_id = i.index_id;
September 28, 2020 at 1:45 pm
It's a shame that the OP didn't explain how they determined the table size.
You can get the information from this select-statement. It shows the size of the table and the size of indexes in 8KB pages.
SELECTi.name,
ps.index_type_desc,
ps.index_id,
ps.index_level,
ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID('databasename'), OBJECT_ID('tablename'), NULL, NULL, 'DETAILED') AS ps
INNER JOIN sys.indexes AS i
ON ps.object_id = i.object_id AND ps.index_id = i.index_id;
Yes, you can certainly do it that way but, if the table is large, that can take an awfully long time and use quite a few resources. With that being said, consider using the following, instead. It's nearly instantaneous and is a whole lot more lightweight insofar as system resources.
SELECT SchemaName = OBJECT_SCHEMA_NAME(object_id)
,ObjectName = OBJECT_NAME(object_id)
,SizeMB = SUM(reserved_page_count /128.0) --There are 128 pages per MB.
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID('SomeSchemaName.SomeObjectNameHere') --Schema name and object name here
AND index_id IN (0,1) --Heap or Clustered Index, which is where the data lives (comment out to include all indexes).
GROUP BY object_id
;
The reason I made the previous post is that I had hoped the OP would respond with more detail because this particular DMV contains information about Reserved, Used, In Row, LOB, and Out of Row information and the OP also didn't mention if he wanted to include the indexes or not.
Depending on what's in the table and how the OP determined the size, they may be quite surprised when they do their SELECT * especially if they have any LOBs or other out-of-row things going on because they may have not taken it all into account.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 28, 2020 at 2:01 pm
Thanks for your responses. The internal report on top table size was sufficient for me
September 28, 2020 at 2:06 pm
.. post deleted. Didn't see the OP's latest post.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 28, 2020 at 2:07 pm
... post deleted. Accidental duplicate.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply