Skip to Main Content

Breadcrumb

May 4th

Question and Answer

Tom Kyte

Thanks for the question, Jon.

Asked: March 05, 2003 - 9:23 pm UTC

Last updated: January 01, 2008 - 6:11 pm UTC

Version: 8.1.7

Viewed 10K+ times! This question is

You Asked

Hi Tom,

I have a few questions about the following:

SQL> drop table a
2 /

Table dropped.

SQL> create table a(x integer, y number(38), z number(5));

Table created.

SQL> select column_name, data_length, data_precision, data_scale
2 from user_tab_columns where table_name = 'A';

COLUMN_NAME DATA_LENGTH DATA_PRECISION DATA_SCALE
------------------------------ ----------- -------------- ----------
X 22 0
Y 22 38 0
Z 22 5 0

1) The data_length is 22 for each column. Does that mean that all number columns use 22 bytes regardless of precision?

2) Column X has a null data_precision - is that a bug; should it read 38? Internally is there any difference between an INTEGER and NUMBER(38). Is not INTEGER just a subtype?

3) Assuming the column is large enough for the data, is there any difference in performance between say a NUMBER(5) and NUMBER(38)? I had thought there could be more LIO required for a larger precision, but maybe this is not the case.

4) Similarly, is there any difference in performance when storing integer data in a column with a scale > 0 or storing in a column with scale = 0. Internally is this floating point arithmentic or all library integer arithmetic?

5) Closely related to 4, if I store 100 in NUMBER(5) is the internal representation different than if I stored 100 in NUMBER(3,2)?

Thanks
Jon

and Tom said...

1) they use UP TO 22 bytes - that is the maximum length. All numbers are stored in a varying width pack decimal like format.

2) Nope, not a bug, just the way it is.

3) A number(5) is not any different from a number(38) if the number(38) only holds data the number(5) can. the 5 is just an "edit", a format, an integrity constraint. nothing more, nothing less. It affects the physical storage not at all.

4) it is all oracle NUMBER math.

5) trick question -- 100 won't fit there:

ops$tkyte@ORA920> create table t ( x number(3,2) );

Table created.

ops$tkyte@ORA920> insert into t values ( 100 );
insert into t values ( 100 )
*
ERROR at line 1:
ORA-01438: value larger than specified precision allows for this column


But assuming you mean 5,2 -- not any different .



use number(s,p) as an integrity constriant, a business rule, an edit. That is what they are good for.



Rating

  (20 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Trick Question...

Jon, March 06, 2003 - 5:28 pm UTC

Good to see you're awake and alert first thing in the morning... obviously you didn't stay up late playing pool last night :)

NUMBER vs NUMBER(6)

A reader, November 21, 2003 - 3:43 pm UTC

Hi, Tom,
Our database tables have a common column whose datatype is NUMBER(6). Normally, it is never exceeding 6 digits. But now because of the business rule changes, we have to increase it to NUMBER(10). In order to avoid this suituation in the future(maybe increase to NUMBER(20) again), and considering there are lots of same coulmns in different tables(some tables already have millions of rows), is it a good idea to just define the column as NUMBER without any precision defined across the board? Are there any physical and logic space differences(concerns) between NUMBER and say NUMBER(10), especially considering a well existing large database?

Thanks


Tom Kyte
November 21, 2003 - 5:50 pm UTC

you can alter a number up in size, it is instantaneous.

use the right datatype.

a number(10) is simply a NUMBER with an edit that says -- YOU BETTER BE 10 digits or less!

it is a constraint, use it.

More regarding space

A reader, November 21, 2003 - 6:15 pm UTC

Hi, TOm,

Appreciate your input.
I agree the following 100%:
"use the right datatype.
a number(10) is simply a NUMBER with an edit that says -- YOU BETTER BE 10 digits or less!"

But I want to know if it will affect database both space and performance wide.

Thanks


Tom Kyte
November 21, 2003 - 10:38 pm UTC

space -- no

performance -- why even consider it, you NEED (desire, want, wish for, must have, etc etc etc) to have integrity....

it will add such a teeny tiny trivial small miniscule amount of "checking" that you won't even see it.

ORA-01438 causes confusion

Marc Blum, April 28, 2005 - 6:20 am UTC

Hi Tom,

you provided an example, how oracle acts when inserting a value of 100 into a column of NUMBER(3,2). Oracle rejects it with ORA-01438: value larger than specified precision allows for this column. As I'm inserting a value with only three digits and the datatype declaration allows three digits, I'm confused. Oracle documentation says at several places: "precision=total number of digits" (I'm fine with this one, 100 has three digits) and "scale=number of digits to the right of the decimal point" (I'm fine too, as there are no digits right to the decimal point). What documentation not says is, that even if I don't give any digits to the right, the declared(!) scale is added to the actual(!) number of left digits and then the precision constraint checks the total.

I'm not happy too with the behaviour of the "precision,scale"-thing, as it mixes up a constraint (precision) with active behaviour (rounding). I would never allow a declarative constraint to change my data.

Tom Kyte
April 28, 2005 - 8:29 am UTC

sorry? I mean, that is the documented way it works and has forever.

if you want the actual number to be stored, you use number.

if you want a scale and precision to be applied, you use that.

Please read again

Marc Blum, April 29, 2005 - 1:51 am UTC

Tom,

I wrote "What documentation not says is, that even if I don't give any digits to the right, the declared(!) scale is added to the actual(!) number of left digits and then the precision constraint checks the total."

Again: the documentation does not describe this behaviour!
Again: the documentation does not describe this behaviour!
Again: the documentation does not describe this behaviour!



Tom Kyte
April 29, 2005 - 8:20 am UTC

what the documentation says, if you use scale, the scale is there -- always and forever.

If you'd like, point me to a direct link on otn.oracle into the concepts guide or sql reference you believe to be misleading.

the concepts guide seemed fairly clear to me as to the documented behaviour.

Doc link

Marc Blum, May 03, 2005 - 2:55 am UTC

SQL reference:

</code> http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10759/sql_elements001.htm#sthref84 <code>

especially "Specifying scale and precision does not force all values to a fixed length." says to me, that 100 is not treated as 100.00



Tom Kyte
May 03, 2005 - 1:22 pm UTC

I'm sorry, what more can I say? It works that way, it has worked that way, it is documented to work that way. The examples right below that quote show what it does.


the full quote is:

Specify the scale and precision of a fixed-point number column for extra integrity checking on input. Specifying scale and precision does not force all values to a fixed length. If a value exceeds the precision, then Oracle returns an error. If a value exceeds the scale, then Oracle rounds it.

....
7456123.89 NUMBER(7,2) exceeds precision


it does not force them to a fixed length, meaning they can be SMALLER but not BIGGER.

???

Marc Blum, May 03, 2005 - 1:48 pm UTC

Please have a close look at the number 100. How many digits do you see? I see three digits.

Tom Kyte
May 03, 2005 - 2:49 pm UTC

Marc,

I don't know what else to say other than "sorry", it works the way it works, it is documented that it works this way, the examples show this working this way.

I'm seriously out of things to say. I don't even know what the point of this one was? I see one significant digit when stored in an Oracle number, but I'd need a number with the correct precision and scale to hold it.

So, I see 1.

But I would need a number(3) at least to hold it.

Marc, Think of It This Way

Mac, May 03, 2005 - 3:57 pm UTC

A numeric variable is:
NUMBER(LEFT + RIGHT, RIGHT)

That is, NUMBER(3, 2) can hold a number having 2 or less digits on the right of the decimal, and consequently upto [3-2=] 1 digit on the left of the decimal.

So a NUMBER(3,2) variable can hold no value greater than 9.99.

HTH.

Let Me Generalize This Further

Mac, May 03, 2005 - 4:13 pm UTC

Think of a numeric variable/column as:
NUMBER(LEFT + NVL(RIGHT, 0), NVL(RIGHT, 0))

^
|
|
|
To the right of this comma
When you specify a number,
You better increase the precision
To avoid the ORA-01438 blunder!

Number precision when used in a table and an object

Abhai, June 06, 2005 - 10:55 am UTC

Hi Tom,

I have a question under the below scenario:


--First I have created a table A as follows:
CREATE TABLE A
(WEIGHT NUMBER(8, 4));


--Then created a TYPE B depending on table A as

CREATE OR REPLACE TYPE "B" AS OBJECT
(WEIGHT NUMBER(6,2)
)

--Then I am creating a view based on object B:
CREATE OR REPLACE VIEW V_OBJECTS OF "B" WITH OBJECT OID (Weight) AS
SELECT weight
FROM A;

-- After that insert the data in the table with the value having 4 decimal places:

INSERT INTO A values (1234.5678);


-- Now I am writing a query to select the weight of the table by using the view V_OBJECTS

based on Type B


Here I assumed that the data which will come up from this query will be for up to 2 decimal

places (1234.57) as I have declared it in type as 2 decimal places.

SELECT weight from V_objects;


But for the above query I have got the result with 4 decimal place (1234.5678).
So is there any mistake in my thinking that the data should be for 2 decimal places.

Thanks,
Abhai

Tom Kyte
June 06, 2005 - 11:24 am UTC

ops$tkyte@ORA9IR2> CREATE OR REPLACE VIEW V OF "B" WITH OBJECT OID (Weight)
  2  AS
  3  SELECT b( weight )
  4    FROM A;
 
View created.


missed the b() 

How to manage scale constraints

Thomas Starr, December 06, 2005 - 11:37 pm UTC

Given they are only constraints, are they deferrable, or can one use RELY or any other means to convert from NUMBER to INTEGER or NUMBER(1) or NUMBER(1,0) without ORA-01440 if data exists?

Tom Kyte
December 07, 2005 - 1:53 am UTC

I call them constraints.

but they are not constraints as in "alter table t add CONSTRAINT..."

they are "immediate"

how to define data type?

A reader, January 31, 2006 - 2:04 am UTC

hi tom,

we have a data model using surrogate keys of type number. data from that model should be used with clients that like to "restrict" the length of those numbers to a certain number of digits -- but we (responsible for the data model) are quite sure that these limitations are subject to change in the future (sooner or later) ...

if such changes would happen we 'd have to "propagate" them to all primary/foreign keys.

to avoid this we 'd prefer to use just number and add a check constraint instead of declaring columns of type number( n, 0 ) where n is based on then client's current preferences ...

what do you mean?

Tom Kyte
January 31, 2006 - 2:24 am UTC

what do you mean what do you mean?


You would in fact just use number(n), and if and when you needed to make that number(n+m), you would/could alter the columns to make them larger.

You would not prefer to use a number + check constraint - I don't see how that would be "easier" or better.

wow

A reader, January 31, 2006 - 2:19 pm UTC

i really thought that changing the data type of a column as part of a RI constraint would cause problems (didn't even try that) ...

thank you ;o)

... and you wouldn't recommend to add such a check constraint just to have an exception raised on attempts to insert values with scales different from 0 either?

Tom Kyte
January 31, 2006 - 3:45 pm UTC

elaborate on your "different from 0".

If you use number(n), only integers will be inserted - we will "round"



A reader, February 01, 2006 - 11:18 am UTC

but we'd prefer an exception instead of such "auto-rounding" ...

Tom Kyte
February 02, 2006 - 3:57 am UTC

but it never has worked that way. It works the way it has always worked and has been documented to work.

If you want to "fail" an attempt, you would use the NUMBER type and a check constraint to fail it

x number check( trunc(x) = x ),

but, I've never felt compelled myself to do that.

Strange

Bruno Araujo, March 08, 2006 - 7:07 am UTC

Tom,

I read you explanation about number precision and scale and I find it jus fine, I'm already used to it. But I don't understand a problem that I'm facing with a particular table:


SQL> desc gc_analises
 Name                            Null?    Type
 ------------------------------- -------- ----
 EMPRESA                         NOT NULL NUMBER(9)
 FILIAL                          NOT NULL NUMBER(9)
 FIRMA                           NOT NULL NUMBER(9)
 SEQ_ANALISE                     NOT NULL NUMBER(9)
 DATA                            NOT NULL DATE
 DATA_RECEBTO                    NOT NULL DATE
 HISTORICO                                VARCHAR2(2000)
 RESPONSAVEL                              NUMBER(9)
 REDUTASE                                 CHAR(4)
 GLOBAL                                   NUMBER(6)
 CRIOSCOPIA                               NUMBER(6,3)
 ESD                                      NUMBER(6,3)
 EST                                      NUMBER(6,3)
 GORDURA                                  NUMBER(6,3)
 CCS                                      NUMBER(8,3)
 DENSIDADE                                NUMBER(9,3)
 ACIDEZ                                   NUMBER(6,3)
 PROTEINA                                 NUMBER(6,3)
 LACTOSE                                  NUMBER(6,3)
 ALIZAROL                                 NUMBER(6)
 TEMPERATURA                              NUMBER(6,3)
 PSICOTROFICOS                            NUMBER(15,3)
 NRO_PESAGEM                              NUMBER(9)
 PLACA                                    VARCHAR2(10)
 COMPARTIMENTO                            NUMBER(1)
 TIPO                            NOT NULL NUMBER(1)
 BALAO                                    NUMBER(2)
 INIBIDOR                                 CHAR(1)
 TIPO_INIB                                NUMBER(1)
 PH                                       NUMBER(6,3)
 PRODUTO                                  CHAR(1)
 PLACA_DEST                               VARCHAR2(10)

SQL> insert into gc_analises values(
  2  1,
  3  1,
  4  408202,
  5  gc_analises_seq.nextval,
  6  '03/03/2006',
  7  '03/03/2006',
  8  'IMPORTACAO AUTOMATICA DO LAUDO NR 42',
  9  2080001,
 10  Null, -- Crioscopia
 11  round(8.52, 1),
 12  round(12.35, 1),
 13  round(3.83, 1),
 14  1099, --CCS
 15  Null, -- Densidade
 16  Null, -- Acidez
 17  round(3.14, 3),
 18  round(4.36, 3),
 19  Null,
 20  Null,
 21  Null,
 22  Null,
 23  Null,
 24  Null,
 25  Null,
 26  Null,
 27  0,
 28  Null,
 29  Null,
 30  Null,
 31  Null,
 32  Null,
 33  Null      
 34   );
1099, --CCS
*
ERRO na linha 14:
ORA-01438: value larger than specified precision allows for this column


SQL> create table a (b number(8,3) not null);

Tabela criada.

SQL> insert into a values (1099);

1 linha criada.

SQL> rollback;

Rollback completo.

SQL> 



I though it was some kind of constraint or trigger that was influencing in my first table, but didn't find any.

What else can cause ORA-1438 if number precision and scale are right (i guess)? 

Sometimes you're just too focus on the wrong thing...

Bruno Araujo, March 08, 2006 - 9:00 am UTC

Tom,

Forget it, please, I just found my error... In fact, I was inserting on wrong column... :(

Number in PL/SQL

Raj, November 29, 2007 - 8:37 am UTC

Hey Tom,
Is there any setting in the database that gives a decimal correct to 14 points in one instance and gives upto 32 in another instance. My basic program is the same in both the instances. It is a PL/SQL Procedure that uses NUMBER without any precision.
Please throw some light on this.
Thanks
Raj
Tom Kyte
November 29, 2007 - 8:57 am UTC

"my basic program" indicates to me that you actually have two different bits of code.

they should be the same if the code is the same.

can you provide a concise counter example that shows different results using the same exact code, same exact inputs.

Number format

Raj, November 30, 2007 - 6:19 am UTC

Hi Tom,

/*************************************************************************************************/
Script
---------------------------------------------------------------------------------------------------
CREATE TABLE TEST_FA (fixed_assets_cost NUMBER, payables_cost NUMBER);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (1212.96946666667, 1212.96946666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (1274.27112, 1274.27112);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (410.7788, 410.7788);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (442.933433333333, 442.933433333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (113.213906666667, 113.213906666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (254.692066666667, 254.692066666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (1249.33166666667, 1249.33166666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (435.139083333333, 435.139083333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (1212.96946666667, 1212.96946666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (2498.66333333333, 2498.66333333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (337.8434, 337.8434);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (239.252973333333, 239.252973333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (77.51735, 77.51735);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (46.51041, 46.51041);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (31.00694, 31.00694);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (32.69768, 32.69768);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (95.91288, 95.91288);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (70.37135, 70.37135);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (32.1321333333333, 32.1321333333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (169.82086, 169.82086);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (236.002, 236.002);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (321.182533333333, 321.182533333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (223.735033333333, 223.735033333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (161.38086, 161.38086);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (97.2719, 97.2719);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (45.22, 45.22);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (415.841533333333, 415.841533333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (1871.50293333333, 1871.50293333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (32.6853550070098, 32.6853550070098);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (241.661316666667, 241.661316666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (2832.61903899884, 2832.61903899884);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (61.24389, 61.24389);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (101.971153826579, 101.971153826579);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (363.546416666667, 363.546416666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (682.61224993078, 682.61224993078);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (1249.33166666667, 1249.33166666667);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (442.933433333333, 442.933433333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (1871.50293333333, 1871.50293333333);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (12.50994, 12.50994);
Insert into TEST_FA (FIXED_ASSETS_COST, PAYABLES_COST) Values (337.8434, 337.8434);
COMMIT;
/*************************************************************************************************/
Code
------------------------------------------------------------------------
Declare
   CURSOR c1 IS SELECT fixed_assets_cost a, payables_cost b FROM TEST_FA;
   i1  number;
   i11 number:=0;
   i2  number;
   i22 number:=0;   
begin
 BEGIN
     SELECT SUM(fixed_assets_cost), SUM(payables_cost)
              INTO i1, i2 FROM TEST_FA;
        END;      
 FOR I IN C1
 LOOP
   i11 := i11 + I.a;
          i22:= i22 + I.b;    
 END LOOP;
  dbms_output.put_line( 'Total'||'*'||i1||'*'||i11||'*'||i2||'*'||i22);
end;

/
----------------------------------------------------------------------------------------------------
Output in DEV
-------------
SQL> @fa2
Input truncated to 1 characters
Total*21840.6259077632111*21840.6259077632111*21840.6259077632111*21840.6259077632111

PL/SQL procedure successfully completed.

Output in PRODUCTION
--------------------
SQL> @fa2
Input truncated to 1 characters
Total**21840.625907763204248744038795814529166**21840.625907763204248744038795814529166

PL/SQL procedure successfully completed.
----------------------------------------------------------------------------------------------------

We have tried the above in development, stage, testing and production instances. The number format is different only in production.
We get more than 30 digits after the decimal in production but only 12 to 14 digits after decimal in all other instances.
Tom Kyte
November 30, 2007 - 1:30 pm UTC

ok, so what is different about production - compare all NLS and init.ora settings, as well as compiler options. version would be "good" as well. operating system.

and what is your iTar number?

Performance impact

Mark Brady, November 30, 2007 - 9:40 am UTC

Above you said,

"performance -- why even consider it, you NEED (desire, want, wish for, must have, etc etc etc) to have integrity.... "

But i thought that it could have *positive* performance impact. Correct this if wrong, but Oracle decides how many rows will fit in a buffer by summing the maximum bytes the columns could hold and then dividing the buffer size by that

so doing what you suggest has a positive impact on performance in *addition* to being an edit, a check, integrity.

Or is this more myth?
Tom Kyte
November 30, 2007 - 2:02 pm UTC

it could - but my point was - this isn't about performance, it is about data integrity...



Girish, December 31, 2007 - 1:42 am UTC

None of the above discussion points explain what is the size of a say column of NUMBER(10) in BYTEs will be
can it be calculated at all ?
Tom Kyte
January 01, 2008 - 6:11 pm UTC

sure it did, the first bullet point stated it:

....
1) they use UP TO 22 bytes - that is the maximum length. All numbers are
stored in a varying width pack decimal like format.
..........

So, a number 10 can store upto +-9999999999, will take a VARYING AMOUNT of storage...

It is a function of the number you actually PLACE IN THERE.

9999999999 takes more space than
1000000000

vsize can be used to see the storage space, we'll compare that to the "length" of the number and see how they differ

ops$tkyte%ORA10GR2> create table t ( x number(10) );

Table created.

ops$tkyte%ORA10GR2> insert into t
  2  select to_number( rpad('9',rownum,'9') )
  3    from all_users
  4   where rownum <= 10;

10 rows created.

ops$tkyte%ORA10GR2> insert into t
  2  select to_number( '1' || rpad('0',rownum-1,'0'))
  3    from all_users
  4   where rownum <= 10;

10 rows created.

ops$tkyte%ORA10GR2> insert into t
  2  select -x from t;

20 rows created.

ops$tkyte%ORA10GR2> set numformat 99999999999
ops$tkyte%ORA10GR2> select x, vsize(x), length(x) from t;

           X     VSIZE(X)    LENGTH(X)
------------ ------------ ------------
           9            2            1
          99            2            2
         999            3            3
        9999            3            4
       99999            4            5
      999999            4            6
     9999999            5            7
    99999999            5            8
   999999999            6            9
  9999999999            6           10
           1            2            1
          10            2            2
         100            2            3
        1000            2            4
       10000            2            5
      100000            2            6
     1000000            2            7
    10000000            2            8
   100000000            2            9
  1000000000            2           10
          -9            3            2
         -99            3            3
        -999            4            4
       -9999            4            5
      -99999            5            6
     -999999            5            7
    -9999999            6            8
   -99999999            6            9
  -999999999            7           10
 -9999999999            7           11
          -1            3            2
         -10            3            3
        -100            3            4
       -1000            3            5
      -10000            3            6
     -100000            3            7
    -1000000            3            8
   -10000000            3            9
  -100000000            3           10
 -1000000000            3           11

40 rows selected.



so, it takes between 2 to 7 bytes to store these 40 numbers... Because of the significant digits - the 999999's take more space than 10000's will...