On comparing Mysql and Postgres table sizes we found that:
Postgre Table size (4758390 rows) (vanilla postgres): 1402MB
Data Length = 1063MB
Index Length = 339MB
Mysql Table Size (4758390 rows) (with Inno DB): 1056MB
Data Length = 845MB
Index Length = 211MB
The tables have the following schema:-
The schema:-
MySQL
int(11)
varchar(15)
datetime
float
float
float
float
float
double
double
double
float
longtext
double
double
int(11)
double
float
int(11)
int(11)
float
int(11)
int(11)
int(11)
int(11)
varchar(50)
int(11)
int(11)
int(11)
Postgres
serial
varchar
timestamp
double precision
double precision
double precision
double precision
double precision
numeric
numeric
numeric
double precision
varchar
numeric
numeric
double precision
numeric
double precision
integer
integer
double precision
integer
integer
integer
integer
varchar
integer
integer
integer
The query used to calculate the sizes for the tables are:-
MySQL
SELECT table_name AS `Table`,data_length, index_length,
round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB`
FROM information_schema.TABLES
WHERE table_schema = "DB_NAME
AND table_name = "TABLE_NAME";
Postgres
SELECT pg_size_pretty(pg_total_relation_size('TABLE_NAME'));
Edit:-
Indexes in MySQL: Size
(varchar(15),datetime) -> 133 MB
(datetime) -> 78 MB
Indexes in Postgres: Size
(varchar,timestamp) -> 339 MB
I am new to databases and wondering how is this possible.
You're using data types with different sizes:
Mysql floats are 4 bytes vs postgresql doubles which are 8 bytes
Mysql datetime looks like 4 bytes (I was unable to find clear documentation) whereas postgreql timestamp is 8 bytes.
Mysql integer(11) is 4 bytes, while for Postgresql numeric The actual storage requirement is two bytes for each group of four decimal digits, plus three to eight bytes overhead
Related
This question already has answers here:
Types in MySQL: BigInt(20) vs Int(20)
(6 answers)
Closed 5 years ago.
mysql jdbc: what is column size for BIGINT?
jdbc:
id BIGINT(20)
ResultSet columns = databaseMetaData.getColumns("foo", "bar", "table", "id");
columns.next();
int columnSize = columns.getInt(7);
the columnSize is 19. Is it 19 bytes?
Q: What is column size for BIGINT?
The MySQL BIGINT datatype is a 64-byte signed integer. From a JDBC resultset, that can be handled in Java as a long.
With the unsigned variant, the MySQL BIGINT UNSIGNED dataype, that could be handled as java.math.BigInteger. (The maximum value of MySQL BIGINT UNSIGNED exceeds the maximum value of Java long.)
Q: Is it 19 bytes?
The longest string value that MySQL will return for a BIGINT would be 20 characters. The lowest possible value for a MySQL BIGINT, represented as a character string is '-9223372036854775808'. (That's 19 digits, but an extra character is required for the minus sign.)
The largest value of BIGINT would have a string representation of 19 characters.
For the unsigned variant BIGINT UNSIGNED the largest value would be represented as 20 decimal digits, thus 20 characters.
In terms of storage in the MySQL database, the BIGINT datatype requires eight bytes.
I want to record a call duration values in a data base..Which is better , Float or Decimal?
I would suggest to use DECIMAL UNSIGNED
ALTER TABLE `tablename` ADD `call_duration` DECIMAL( 6, 2 ) UNSIGNED NOT NULL
Depending on the granularity you need to store (i.e. parts of seconds) I'd go with either an unsigned smallint (2 bytes) or an unsigned int (4 bytes).
http://dev.mysql.com/doc/refman/5.0/en/integer-types.html
By definition:
VARCHAR: The range of Length is 1 to 255 characters. VARCHAR values are sorted and compared in case-insensitive fashion unless the BINARY keyword is given. x+1 bytes
TINYBLOB, TINYTEXT: A BLOB or TEXT column with a maximum length of 255 (2^8 - 1) characters x+1 bytes
So based on this, I creaate the following table:
CREATE TABLE `user` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255),
`lastname` tinytext,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
Or is it better to create a varchar or tinytext and why?
Is it the same for:
VARCHAR: The range of Length is > 255 characters. VARCHAR values are sorted and compared in case-insensitive fashion unless the BINARY keyword is given. x+2 bytes
BLOB, TEXT A BLOB or TEXT column with a maximum length of 65535 (2^16 - 1) characters x+2 bytes
In this case varchar is better.
Note that varchar can be from 1 to 65535 chars.
Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions. The effective maximum length of a VARCHAR in MySQL 5.0.3 and later is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used. See Section E.7.4, “Table Column-Count and Row-Size Limits”.
Blobs are saved in a separate section of the file.
They require an extra fileread to include in the data.
For this reason varchar is fetched much faster.
If you have a large blob that you access infrequently, than a blob makes more sense.
Storing the blob data in a separate (part of the) file allows your core data file to be smaller and thus be fetched quicker.
How do I represent this data in mysql?
16 bit unsigned integer -----Range: 0x0000 - 0xFFF7
64 bit unsigned int. Depicted as xx:xx:xx:xx:xx:xx:xx:xx -----Range: 0x0000 - 0xFFFFFFFFFFFFFFFF
2 bits ----- 00 - None, 01 - Residential Security, 10 - High Security
32 bit unsigned int
Should I convert everything to string and convert it at application layer?
According to MySQL's Overview of Numeric Types:
UNSIGNED SMALLINT: range is 0 to 65535. This would be sufficient for 16-bit unsigned ints.
UNSIGNED TINYINT: range is 0 to 255. Sufficient for 2-bit unsigned int. It appears you would need to preserve leading zeroes, so use ZEROFILL too. To keep the value to just two characters wide, you can specify UNSIGNED ZEROFILL TINYINT(2).
UNSIGNED INT: range is 0 to 4294967295. Sufficient for 32-bit unsigned int.
UNSIGNED BIGINT: range is 0 to 18446744073709551615. See below:
The last one, the 64-bit unsigned int, has a couple of caveats, from the above linked page:
All arithmetic is done using signed BIGINT or DOUBLE values, so you should not use unsigned big integers larger than 9223372036854775807 (63 bits) except with bit functions! If you do that, some of the last digits in the result may be wrong because of rounding errors when converting a BIGINT value to a DOUBLE.
You can always store an exact integer value in a BIGINT column by storing it using a string. In this case, MySQL performs a string-to-number conversion that involves no intermediate double-precision representation.
The -, +, and * operators use BIGINT arithmetic when both operands are integer values. This means that if you multiply two big integers (or results from functions that return integers), you may get unexpected results when the result is larger than 9223372036854775807.
MySQL support several data types. See MySQL Data Types
UNSIGNED BIGINT : 8-byte (64-bit) integer
UNSIGNED INT : 4-byte (32-bit) integer
UNSIGNED SMALLINT : 2-byte (16-bit) integer
For the 2-bit type, you may use the TINYINT (8-bit) or the ENUM datatype.
What's the difference in int(11) and int(11) UNSIGNED ?
An UNSIGNED type cannot be negative, but on the other hand it has twice as large a range for the positive integers. The types TINYINT, SMALLINT, MEDIUMINT,
INT and BIGINT all have signed and unsigned versions.
For INT the ranges are defined as follows:
Type Storage Min Max
INT 4 -2147483648 2147483647
INT UNSIGNED 4 0 4294967295
The signed and unsigned types take the same storage space (4 bytes for INT).
See the documentation for more details.
INT goes from -2147483648 to +2147483647
UNSIGNED INT goes from 0 to 4294967295
the 11 between the braces has no effect on the number, just how it's displayed.
UNSIGNED means that it can hold only nonnegative values, i.e. it can't hold for example -20
UNSIGNED is exactly that, its all positive (no sign) numbers. The size of bytes is the same, but if your data is never negative you can get larger positive numbers out of it. The 11 is the default of how many characters it will fetch and display. For the exact size, do a search for the DBMS you are using and the type.
All integer types can have an optional (nonstandard) attribute UNSIGNED. Unsigned type can be used to permit only nonnegative numbers in a column or when you need a larger upper numeric range for the column. For example, if an INT column is UNSIGNED, the size of the column's range is the same but its endpoints shift from -2147483648 and 2147483647 up to 0 and 4294967295.
see here: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
The unsigned one can't hold negative numbers.
An unsigned integer can handle values from 0 to 2^(size in bits of the integer field). A signed integer can handle values from -2^(size of the integer field-1) to 2^(size of the integer field-1)-1.
I think you may want to know the difference between int and int(10).
Let's give an example for int(10) one with zerofill keyword, one not, the table likes that:
create table tb_test_int_type(
int_10 int(10),
int_10_with_zf int(10) zerofill,
unit int unsigned
);
Let's insert some data:
insert into tb_test_int_type(int_10, int_10_with_zf, unit)
values (123456, 123456,3147483647), (123456, 4294967291,3147483647)
;
Then
select * from tb_test_int_type;
# int_10, int_10_with_zf, unit
'123456', '0000123456', '3147483647'
'123456', '4294967291', '3147483647'
We can see that
with keyword zerofill, num less than 10 will fill 0, but without zerofill it won't
Secondly with keyword zerofill, int_10_with_zf becomes unsigned int type, if you insert a minus you will get error Out of range value for column...... But you can insert minus to int_10. Also if you insert 4294967291 to int_10 you will get error Out of range value for column.....
Conclusion:
int(X) without keyword zerofill, is equal to int range -2147483648~2147483647
int(X) with keyword zerofill, the field is equal to unsigned int range 0~4294967295, if num's length is less than X it will fill 0 to the left