Quantcast
Channel: CodeFari
Viewing all articles
Browse latest Browse all 265

PostgreSQL: Materialized View

$
0
0

In this article we will learn about Materialized View, its need, and advantage. Also, we will learn how we can manage it in PostgreSQL? Before start Materialized View, you should take a look at the article VIEW.

Materialized View in PostgreSQL


A traditional view is the group of complex queries; sometimes, it becomes expensive and slow. To resolve this problem, PostgreSQL introduced to Materialized View.

A materialized View is stored on disk that defined by the database query. Like a traditional view, the underlying query is not executed every time when you access the Materialized View. 

Syntax to create the materialized view:



CREATE MATERIALIZED VIEW view_name AS query;


The Materialized View is persisting physically into the database so we can take the advantage of performance factors like Indexing, etc. According to the requirement, we can filter the records from the underlying tables. Now, one thing comes in our mind if it looks like a table then how both different are.

You cannot insert, update or delete the records into the materialized view directly through PostgreSQL SQL statement; you have to refresh the view.

Syntax to refresh materialized view:



REFRESH MATERIALIZED VIEW view_name;


Syntax to index materialized view:



CREATE INDEX my_index_1 ON view_name (column_name);


Example of Materialized View in PostgreSQL


Suppose we have tables like below.

Employee table


CREATETABLEpublic.employee
(
    empidserialNOTNULL,-- primary key
    fnametext,
    lnametext,
    usernametext,
    passwordtext,
    contacttext,
    salarynumericNOTNULLDEFAULT 0.0,
    dojdateNOTNULL,
    manageridbigint,
    ageinteger,
    CONSTRAINTemployee_primarykeyPRIMARYKEY (empid),
    CONSTRAINT"uk_UserName"UNIQUE (username),
    CONSTRAINTchk_employee_ageCHECK (age> 18)
);


Employee Address table


CREATETABLEpublic.address
(
    idserialNOTNULL,
    empidintegerNOTNULL,-- reference of employee
    address1text,
    address2text,
    citytext,
    statetext,
    countrytext,
    CONSTRAINTpk_address_idPRIMARYKEY (id)
);


I am creating customer Materialized View as mvw_customer



CREATEMATERIALIZEDVIEWmvw_customerAS
SELECT
  e.fname||' '||e.lnameASname,
  e.contact,
  a.city,
  a.state,
  a.country
FROMemployeee
  INNERJOINaddressa
  ONe.empid=a.empid;


Now you can fetch the customers needed records using VIEW. 


SELECT*FROM mvw_customer


Refresh Materialized View mvw_customer



REFRESHMATERIALIZEDVIEWmvw_customer;


Create an index on Materialized View



CREATEINDEXmvw_index_1ONmvw_customer(name);


When Should You Use Materialized View


It is related to performance optimization, if you can't bear slow performance of the traditional view then you should use the materialized view that gives the better performance, especially if you add the appropriate indexes.


Viewing all articles
Browse latest Browse all 265

Trending Articles