Reputation: 26412
The main integer fields in Django are the following,
Integer Field
An integer. Values from -2147483648 to 2147483647 are safe in all databases supported by Django. The default form widget for this field is a NumberInput when localize is False or TextInput otherwise.
SmallIntegerField
Like an IntegerField, but only allows values under a certain (database-dependent) point. Values from -32768 to 32767 are safe in all databases supported by Django.
BigIntegerField
A 64 bit integer, much like an IntegerField except that it is guaranteed to fit numbers from -9223372036854775808 to 9223372036854775807. The default form widget for this field is a TextInput.
If I have a number, 33432
(some number that fits in all of the fields), If I choose to store the same number in all of the below fields, will there be an excess use of memory with both the database or at the runtime?
number0 = models.SmallIntegerField()
number1 = models.IntegerField()
number2 = models.BigIntegerField()
My database is PostgreSQL.
Upvotes: 4
Views: 2800
Reputation: 656616
Most operations are fastest for plain integer
, but the difference is very small and typically the least of your concerns when optimizing performance.
Storage size is more relevant, but the difference between various integer types is still very small and often hardly relevant, sometimes lost to padding and alignment. There are other data types that can waste much more space.
smallint
(int2
) occupies 2 bytes on disk and in RAM.
integer
(int
, int4
) occupies 4 bytes on disk and in RAM.
bigint
(int8
) occupies 8 bytes on disk and in RAM.
Details for numeric types in Postgres in the manual.
There are various other factors for actual storage size. You have to consider page and tuple overhead, alignment and padding, possible NULL values, indexing ...
Details:
There is some potential for optimizing, but typically not much. Best concentrate on choosing an appropriate data type for your data and don't worry about minor differences in storage and performance, unless you know exactly what you are doing.
Upvotes: 2
Reputation: 7919
Yes, the memory storage and runtime memory allocated for your numeric data will be directly proportional to the byte size of the numeric structure you choose.
There are some compression methods such as changing integers and decimals to the variable-length format instead of their native fixed-length format for SQL server. However, they introduce higher CPU usage as mentioned here.
Upvotes: 0