In this post, I am sharing a demonstration on how to load a table data into the Buffer Cache of PostgreSQL?

If your table available in the Buffer Cache, you can reduce the cost of DISK I/O. The similar feature of Memory Engine or Database In-Memory concept.

But this is not always good, because compare to DISK we have always the limited size of Memory and memory is also require of OS. But in some special cases, we can load frequently used table into Buffer Cache of PostgreSQL.

Before loading any table into the Buffer Cache, you must check the size of the table and the available size of Buffer Cache.

Using pg_prewarm module we can do this. It provides a convenient way to load relation data into either the operating system buffer cache or the PostgreSQL buffer cache.

Once you perform the below test, next question would be “How to check the status of Buffer Cache for each table?”
Please visit tomorrow’s article for this solution…

PostgreSQL: Script to check the status of Shared Buffer (Use pg_buffercache)

Please check the below demonstration:

Create two sample tables:

CREATE TABLE tbl_ItemTransactions_1
 (
     TranID SERIAL
     ,TransactionDate TIMESTAMPTZ
     ,TransactionName TEXT
 );
 
INSERT INTO tbl_ItemTransactions_1
(TransactionDate, TransactionName)
SELECT x, 'dbrnd' 
FROM generate_series('2010-01-01 00:00:00'::timestamptz, '2018-02-01 00:00:00'::timestamptz,'1 minutes'::interval) a(x);

CREATE TABLE tbl_ItemTransactions_2
 (
     TranID SERIAL
     ,TransactionDate TIMESTAMPTZ
     ,TransactionName TEXT
 );
 
INSERT INTO tbl_ItemTransactions_2
(TransactionDate, TransactionName)
SELECT x, 'dbrnd' 
FROM generate_series('2010-01-01 00:00:00'::timestamptz, '2018-02-01 00:00:00'::timestamptz,'1 minutes'::interval) a(x);

Create pg_prewarm extension:

CREATE EXTENSION pg_prewarm;

Now, prefatch the tbl_ItemTransactions_1 table using pg_prewarm:

SELECT pg_prewarm('tbl_ItemTransactions_1');

Check the execution plan of tbl_ItemTransactions_1:
The execution plan of prefatched table is quite faster than normal table.

EXPLAIN ANALYZE SELECT *FROM tbl_ItemTransactions_1;

Planning time: 0.130 ms
Execution time: 356.237 ms

Check the execution plan of tbl_ItemTransactions_2:

EXPLAIN ANALYZE SELECT *FROM tbl_ItemTransactions_2;

Planning time: 0.210 ms
Execution time: 752.010 ms

In the previous post, I had explained the basic theory on the Heap Table of Database Technology.
In this post, I am going to explain the Heap table terminology of MySQL.

MySQL Memory Storage Engine also called as Heap Storage structure.

Using Memory Storage Engine, you can store a table of data in server memory for fast retrieval.
This table of data also supports B-Tree index so you can get a result in a best-optimized way. Auto_Increment also supported by the Tables of Memory Engine.

There might be chances of loss data when any hardware crashes or power outage of Server Memory.

You can store and use only those data which are in temporary use and make sure that data in memory engine has always back up in physical stored table.

When to use Memory Engine of MySQL ?

If data are non-critical, need fast retrieval and only for read-only access with a minimum of updates.
The volume of data can be fit into Memory area because it internally uses the swap out of virtual memory pages.

Brief details of Memory Engine Mechanism:

The table of Memory Engine stores it’s table definition into one disk file, and extension of this file is .frm.
All other data stores in a specified area of memory.
The data in memory table is not only for one single connection, it is available for all running related connections and sessions of MySQL Server.

Create sample table using Memory Engine:

CREATE TABLE Test (TestNo INT,TestName VARCHAR(50)) ENGINE = MEMORY;

This all basic about MySQL Memory or Heap Engine.

Any confusion, like difference between Temporary table and Memory table.
If yes, then please visit next post.