As a database professional, I work with both databases on a regular basis, and I typically use all the features of both databases for design and implementation.
I have got many replies to write about the core differences between PostgreSQL and MySQL.

As innovation on these databases has progressed, each development community has actively made changes to address their respective sets of perceived disadvantages.
The result that it has gotten more difficult to objectively determine which database is likely to be better suited for a given application.

MySQL is controlled by Oracle, whereas Postgres is available under an open-source license from the PostgreSQL Global Development Group.

PostgreSQL is closer to the ANSI SQL standard, MySQL is closer to the ODBC standard.

One of the most notable differences between MySQL and PostgreSQL is the fact that you can’t do nested subqueries of subselects in MySQL. MySQL doesn’t support CTE, window functions, full outer joins and arrays.

Compare to PostgreSQL, MySQL has its own large user community and various type of materials.

MySQL uses nonstandard ‘#’ to begin a comment line and PostgreSQL use ‘–‘ to begin a comment line.

MySQL provides different type of table storage engines like: InnoDB, MyIsam, Memory. PostgreSQL does not provide different type of table stroage engines.

PostgreSQL is case-sensitive for string comparisons. The field “DbRnd” is not the same as the field “dbrnd”. This is a big change for many users from MySQL and other small database systems.

PostgreSQL has some nice features like: generate_series, custom aggregate functions, arrays etc. other hand MySQL has also some nice feature like: session variables in queries, FORCE INDEX, etc.

In PostgreSQL, when you are inside a transaction almost any operation can be undone. There are some irreversible operations (like creating or destroying a database or tablespace), but normal table modifications can be backed out by issuing a ROLLBACK via its Write-Ahead Log design.

MySQL doesn’t support any sort of rollback when using MyISAM. With InnoDB, the server has an implicit commit that occurs even if the normal auto-commit behavior is turned off. This means that any single table alteration or similar change is immediately committed.

Postgres obliterates MySQL in all manner of query-level goodness, and we can use Postgres for data mining and batch analytics databases, where we run lots of very large, hand-coded queries that can take advantage of Postgres’ advantages in join methods (MySQL only supports Nested Loop and Nested Loop over Index, while Postgres supports numerous methods), generally richer querying capabilities, and other good stuff like partial indexes can be used extensively.

PostgreSQL uses a robust locking model called MVCC that limits situations where individual clients interfere with each other. A short summary of the main benefit of MVCC would be “readers are never blocked by writers”.

MySQL’s InnoDB implements MVCC using a rollback segment and InnoDB databases supports all four SQL standard transaction isolation levels.

PostgreSQL uses cost-based query optimization methods in order to get good performance for many different types of joins. Query costs are assessed based on planner statistics collected when tables are analyzed combined with adjustable planner costs and advanced features such as the Genetic Query Optimizer.

MySQL doesn’t have this level of sophistication in its planner, and the tunables for Controlling Query Optimizer Performance are crude. Developers instead do things like explicitly provide index hints to make sure joins are executed correctly.

PostgreSQL has different replication options than MySQL. MySQL has no point-in-time recovery.

One operation that PostgreSQL is known to be slow performing is doing a full count of rows in a table, typically using this SQL:

SELECT COUNT(*) FROM your_table_name;

The reason why this is slow is related to the MVCC implementation in PostgreSQL. The fact that multiple transactions can see different states of the data means that there can be no straightforward way for “COUNT(*)” to summarize data across the whole table; PostgreSQL must walk through all rows, in some sense.

In MySQL, MyISAM tables cache the row count information, making this type of count operation almost instant. But if you’re using InnoDB instead, this is no longer the case and on InnoDB can’t assume that a full row count will be fast.

In this post, I am sharing a script to find the total occupied size of each Storage Engine of MySQL Server.

MySQL Provides different types of storage engines like: MyISAM, InnoDB, Memory.
I have seen few questions on MySQL Forum like how to migrate MyISAM tables into InnoDB engines and what would be the storage size difference.

Periodically, Database Administrators have to check the occupied size of each different MySQL Storage Engine which helps them to take decisions on internal migration or for any other reason.

SELECT
	COUNT(*) AS TotalTableCount
	,table_schema
	,CONCAT(ROUND(SUM(table_rows)/1000000,2),'M') AS TotalRowCount
	,CONCAT(ROUND(SUM(data_length)/(1024*1024*1024),2),'G') AS TotalTableSize
	,CONCAT(ROUND(SUM(index_length)/(1024*1024*1024),2),'G') AS TotalTableIndex
	,CONCAT(ROUND(SUM(data_length+index_length)/(1024*1024*1024),2),'G') TotalSize	
FROM information_schema.TABLES
GROUP BY ENGINE
ORDER BY SUM(data_length+index_length) 
DESC LIMIT 10;

In this post, I am going to discuss MySQL InnoDB File-Per-Table tablespaces.
What are the advantages and disadvantages? How to enable and disable it?

By default, The InnoDB stores tables and indexes into the system tablespace. If we want to create separate .idb and .frm file for each table, we should enable innodb_file_per_table.

How to Enable and Disable Innodb_file_per_table?

To Enable:
Add below line into [mysqld] section of my.cnf file and restart the MySQL Server. It will create two separate file for each table, .idb file for data and .frm file for table definition.

[mysqld]
innodb_file_per_table=1

-- We can also run this command and restart MySQL Server. 
SET GLOBAL innodb_file_per_table=1;

To Disable:
Simply, you can remove innodb_file_per_table line from my.cnf and restart the server. Now newly created table stores into common tablespace (ibdata1).

Advantages to enable innodb_file_per_table:

• The Truncate Table operation runs faster when we have separate.idb file.
• We can reclaim disk space by truncating and dropping a single table. On the other side, with the single table space we can use this free space only for new InnoDB data.
• We can easily run OPTIMIZE TABLE on individual Table files.
• We can easily store and move individual table.
• We can use features like compressed and dynamic row formats.
• We can quickly perform backup and restore of individual tables.

Disadvantages to enable innodb_file_per_table:

• The management of each different file is very difficult and time taking exercise.
• Each different file has unused space so we require to perform OPTIMIZE TABLE on each individual file.
• Mysqld has to open file handler per table, which may reduce the performance of MySQL Server.
• For every action of each file buffer pool is scanned, which reduce the performance of MySQL Server.

What is a Multithreaded Database?

For any database system bottleneck is a disk and CPU which spikes during the heavy operations like arithmetic operations, bulk load operation.

In the Multithreaded Database, the result set of a query can split and process into different cores of the server.
Internally Multithreaded Database uses a thread for various purposes like background SQL Job, reading/writing, locking, unique operation, and Network IO.

In this post, I am going to show how to configure MySQL InnoDB Engine for the Multithreaded purpose.

InnoDB Engine is an already performing great with a single CPU environment, but if you want to take advantage of Multi Threading, you should configure below list of parameters.

innodb_thread_concurrency : you can set the number of concurrent threads between 0 to 1000. Default is 0 and this interpreted as infinite concurrency.

innodb_concurrency_tickets : Default is 500, the Min value is 1 and Max value is 4294967295. You can set large values in which large transactions spend less time for waiting and You can set small value in which small transactions spend less time for waiting.
You can balance this value by up or down to find the balance between larger and smaller transactions.

innodb_thread_sleep_delay : How long InnoDB threads sleep before joining the InnoDB queue, in microseconds. The default value is 10000. A value of 0 disables sleep.

innodb_read_io_threads : Default is 4, Minimum value is 1, Maximum value is 64. This defines the total number of threads for reading.

innodb_write_io_threads : Default is 4, Minimum value is 1, Maximum value is 64. This defines the total number of threads for writing.

innodb_read_ahead_threshold : Default value is 56 and Maximum value is 64. It uses to fetch pages in the buffer pool and read at least 56 pages sequentially. We can also find how many pages are read through this read-ahead mechanism and how many pages removed from buffer pool without access.
SHOW ENGINE INNODB STATUS shows the rate of how many pages are read per second and how many pages removed from the buffer pool.

innodb_rollback_on_timeout : This is a boolean parameter and if it is true and a timeout occurs, InnoDB to abort and roll back the entire transaction.

For more details you can visit this MySQL Official Link:

In this post, I am providing a script for determining the size of innodb_buffer_pool_size in MySQL Server.

The Buffer pool is essential for the InnoDB engine because InnoDB maintains the storage area for caching data and indexes in memory.

I have a rough figure like, if you have 3 GB of InnoDB data and indexes, you require at least 1 GB size of innodb_buffer_pool_size.

Below is a script to calculate the size for InnoDB buffer pool.

SELECT 
	CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) AS RIBPS 
FROM
(
	SELECT SUM(data_length+index_length) Total_InnoDB_Bytes
	FROM information_schema.tables WHERE engine='InnoDB'
) AS T;

After executing above statement, You will get one RIBPS value. e.g. result in 2 RIBPS, so you require 2 GB size of the buffer pool.
You can change this parameter in the config file and restart your MySQL Service.

InnoDB reserves additional memory for buffers and control the structures, so that the total allocated space is approximately 10% greater than the specified size.

InnoDB:

• InnoDB implements row-level.
• InnoDB has better crash recovery option.
• FULLTEXT Search indexes doesn’t support until v5.6.
• Implemented transactions, foreign keys and relationship constraints.
• ACID Properties is supported.
• It has Buffer Pool to cache data and index pages.
• You can take backup of InnoDB tables using just a snapshot of the filesystem.

MyISAM:

• MyISAM can do only a table-level lock.
• FULLTEXT Search is supported.
• The main mechanism used is the key cache. It only caches index pages from .MYI files.
• ACID Properties is not supported.
• COUNT(*) performance is very fast.
• Supported high level table compression.
• You require mysqldump to take backup of MyIsam table.