Guys below is one of the questions i had faced.
I posted this question on several blogs and following is the answer i received.
Question:
Hi allWhile testing some issue i came across this phenomenon.
I have created a table with one column of CHAR(20).
When i insert a row in this table , the size of the table increases by 512
bytes and not 20 bytes.
I believe it should increase by 20 bytes as i am inserting data only to
CHAR(20) field.
I am not able to understand , why the size has been increasing in multiple
of 512 bytes and not 20 bytes.
Following is what i had ran:
CREATE TABLE RESTORE_TABLES.TESTTABLE, NO FALLBACK
(
FIELD1 CHAR(20)
);
/* CREATED A TABLE WITH ONLY 1 COLUMN fo CHAR(20)*/
SELECT SUM(CurrentPerm) FROM DBC.ALLSPACE WHERE
DatabaseName='RESTORE_TABLES' AND TableName='TESTTABLE'
Result is 196608.00 BYTES.
INSERT INTO RESTORE_TABLES.TESTTABLE VALUES('ABC')
SELECT SUM(CurrentPerm) FROM DBC.ALLSPACE WHERE
DatabaseName='RESTORE_TABLES' AND TableName='TESTTABLE'
Result is 197120.00 . Thus the increase is by 512 bytes.
INSERT INTO RESTORE_TABLES.TESTTABLE VALUES('CDF')
SELECT SUM(CurrentPerm) FROM DBC.ALLSPACE WHERE
DatabaseName='RESTORE_TABLES' AND TableName='TESTTABLE'
Result is 197632.00 . Thus the increase is again by 512 bytes.
INSERT INTO RESTORE_TABLES.TESTTABLE VALUES(NULL)
SELECT SUM(CurrentPerm) FROM DBC.ALLSPACE WHERE
DatabaseName='RESTORE_TABLES' AND TableName='TESTTABLE'
Result is 198144.00. For null value also increase is by 512 bytes.
Can anybody please help me understand why the size is in multiples of 512
bytes.
Answer:
This answer is consolidated from several responses that i received for my question.
Blocks consists of sectors. A sector is 512 bytes.
SO whenever we insert a unique value, it hashes differently and hence goes to a new AMP.
On each of the AMP a sector (which is 512 bytes) is allocated.
If i had added same
values .ie 'ABC' again then it would go again to same amp and in this
case he size wont increase by 512 bytes as it will be accommodated in
the same sector that was earlier allocated.
No comments:
Post a Comment