PostgreSQL Database Slides

Prepared by Sout Saret
PostgreSQL
Position: Senior Database Administrator

Introduction
• PostgreSQL is an Object-relational Database Management System (ORDBMS) based on POSTGRES, Version 4.2, developed at
the University of California at Berkeley Computer Science Department.
• PostgreSQL supports a large part of the SQL standard and offers many modern features:
- Complex Queries
- Foreign Keys
- Triggers
- Updatable Views
- Transactional Integrity
- Multi Version Concurrency Control (MVCC)
• PostgreSQL can be extended by the user in many ways, for example by adding new:
- Data Types
- Functions
- Operations
- Aggregate Functions
- Index Method
-Procedural Language

History
• With over two decades of development behind it, PostgreSQL is now the most advanced open-source database available
anywhere.
• The POSTGRES project, led by Professor Michael Stonebraker, was sponsored by the Defense Advanced Research Projects
Agency (DARPA), the Army Research Office (ARO), the National Science Foundation (NSF), and ESL, Inc. The
implementation of POSTGRES began in 1986.
• In 1994, Andrew Yu and Jolly Chen added an SQL language interpreter to POSTGRES. Under a new name, Postgres95 was
subsequently released to the web to find its own way in the world as an open-source descendant of the original POSTGRES
Berkeley code.
• In 1995, POSTGRES was renamed as PostgreSQL.

Installation
• To make an installation PostgreSQL. We have two ways:
1. Install PostgreSQL from source code:
You can go to website to download from http://www.postgresql.org/ftp/source
2. Install PostgreSQL from file:
You can go to website to download binary file from http://www.postgresql.org/download/.
Note: In database jargon, PostgreSQL uses a client/server model. A PostgreSQL session consists of the following cooperating
processes (programs):
- A server process, which manages the database files, accepts connections to the database from client
applications, and performs database actions on behalf of the clients. The database server program is called postgres.
- The user's client (frontend) application that wants to perform database operations. Client applications can be
very diverse in nature: a client could be a text-oriented tool, a graphical application, a web server that accesses the database
to display web pages, or a specialized database maintenance tool. Some client applications are supplied with the PostgreSQL
distribution; most are developed by users.

Manipulated Database
• To create a database, we have two ways to create:
1. First way: we can use by command to create:
Ex: createdb dbname
2. Second way: we can use by sql standard to create:
Ex: create database dbname;
• To drop a database, we have two ways to drop:
1. First way: we can use by command to drop:
Ex: dropdb dbname
2. Second way: we can use by sql standard to drop:
Ex: drop database dbname;

Accessing Database
• To access to PostgreSQL database, we have several ways:
1. Using PostgreSQL Terminal:
PostgreSQL provides a terminal to access, is called psql.
$ psql dbname
2. Using GUI Tools:
GUI Tools that can access to PostgreSQL such as Navicat, PgAdmin, PHPPgAdmin, …
3. Using Customize Applications:
Using one of the several available language bindings.

SQL Language
• Every Databases, they have to follow the SQL standard. The SQL provides as below:
1. Data Definition Language (DDL)
2. Data Manipulation Language (DML)
3. Data Control Language (DCL)
4. Transaction Control (TCL)

DDL
• Data Definition Language (DDL) statements are used to define the database structure or schema.
Some examples:
1. CREATE - to create objects in the database
2. ALTER - alters the structure of the database
3. DROP - delete objects from the database
4. TRUNCATE - remove all records from a table, including all spaces allocated for the records are removed
5. COMMENT - add comments to the data dictionary
6. RENAME - rename an object

DML
• Data Manipulation Language (DML) statements are used for managing data within schema objects.
Some examples:
1. SELECT - retrieve data from the a database
2. INSERT - insert data into a table
3. UPDATE - updates existing data within a table
4. DELETE - deletes all records from a table, the space for the records remain
5. MERGE - UPSERT operation (insert or update)
6. CALL - call a PL/SQL or Java subprogram
7. EXPLAIN PLAN - explain access path to data
8. LOCK TABLE - control concurrency

DCL
• Data Control Language (DCL) statements.
Some examples:
1. GRANT - gives user's access privileges to database
2. REVOKE - withdraw access privileges given with the GRANT command

TCL
• Transaction Control (TCL) statements are used to manage the changes made by DML statements. It allows statements to
be grouped together into logical transactions.
Some example:
1. COMMIT - save work done
2. SAVEPOINT - identify a point in a transaction to which you can later roll back
3. ROLLBACK - restore database to original since the last COMMIT
4. SET TRANSACTION - Change transaction options like isolation level and what rollback segment to use

Creating a New Table
• You can create a table using CREATE keyword.
Syntax:
CREATE TABLE table_name (
field_name data_type constrain_name,
field_name1 data_type1 constrain_name1
);
Exampple:
CREARE TABLE employee (
emp_id integer PRIMARY KEY,
emp_name varchar(50) NOT NULL,
emp_gender char(1) NOT NULL,
emp_description varchar(255)
);

Inserting Data into Table
• To insert data into table, we can use INSERT keyword:
We can insert data into table with different ways:
Ex:
- INSERT INTO table_name VALUES (value1,value2,value3); // Insert all fields in table
- INSERT INTO table_name (field1, field2, field3) VALUES (value1,value2,value3); // Insert specific fields in table
- INSERT INTO table_name VALUES (value1,value2,value3), (value4,value5,value6), (value7,value8,value9);
- COPY weather FROM '/home/user/table_name.txt'; // Insert from file into table

Display Data (Querying Data)
• To retrieved data from table, we can use SELECT keyword.
Example:
- SELECT * FROM table_name;
- SELECT field_name1, field_name2, field_name3 FROM table_name;
- SELECT * FROM table_name WHERE condition;
- SELECT * FROM table_nameWHERE condition ORDER BY field_name ASC/DESC;
- SELECT * FROM table_name WHERE condition GROUP BY field_name ORDER BY field_name ASC/DESC;

Updating Data (Modified Data)
• To update or modify data in table, we have to use UPDATE key word:
Example:
- UPDATE table_name SET field_name= value; // Update or Modify all data in a column
- UPDATE table_name SET field_name= value WHERE condition; // Modify with condtion

Deleting Data
• To clear or delete data from table, we have to use DELETE keywork:
Example:
- DELETE FROM table_name; // Clear all Data from table
- DELECT FROM table_nameWHERE condition; // Delete data from table with condition

Joining Table
• Normally, we can query data from one table or multi tables at one time. So this is some examples that is used join:
Example:
- SELECT * FROM table_name; // No join table
- SELECT * FROM table_name1, table_name2 WHERE table_name1.field_name=table_name2.field_name;
- SELECT * FROM table_name1 JOIN table_name2 ON(table_name1.field_name=table_name2.field_name);
- SELECT * FROM table_name1 JOIN table_name2 ON(table_name1.field_name=table_name2.field_name)
WHERE condition;

Creating Views
• Views can be used in almost any place a real table can be used. Building views upon other views is not uncommon.
Example:
- CREATE VIEW view_name AS
SELECT * FROM table_name1
JOIN table_name2 ON(table_name1.field_name=table_name2.field_name)
JOIN table_name2 ON(table_name1.field_name=table_name3.field_name)
WHERE codition;
• To show data from view:
Example:
- SELECT * FROM view_name;

Putting Primary Key & Foreign Key
• We need primary key to unique name data in field of tables:
Example:
- CREATE TABLE parents(
p_id int primarykey,
name varchar(50)
);
• We need foreign key to make relationship between parents table and child table or another tables:
Example:
- CREATE TABLE children(
c_id int primary key,
p_id int references parents(p_id),
name varchar(50)
);

Transaction
• Transactions are a fundamental concept of all database systems. The essential point of a transaction is that it bundles
multiple steps into a single, all-or-nothing operation. The intermediate states between the steps are not visible to other
concurrent transactions, and if some failure occurs that prevents the transaction from completing, then none of the steps
affect the database at all.
• For example, consider a bank database that contains balances for various customer accounts, as well as total deposit
balances for branches. Suppose that we want to record a payment of $100.00 from Alice's account to Bob's account.
BEGIN;
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
SAVEPOINT my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Bob';
-- oops ... forget that and use Wally's account
ROLLBACK TO my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Wally';
COMMIT;

Window Function
• A window function performs a calculation across a set of table rows that are somehow related to the current row. This is
comparable to the type of calculation that can be done with an aggregate function. But unlike regular aggregate functions,
use of a window function does not cause rows to become grouped into a single output row — the rows retain their
separate identities. Behind the scenes, the window function is able to access more than just the current row of the query
result.
• A window function call always contains an OVER clause directly following the window function's name and argument(s).
This is what syntactically distinguishes it from a regular function or aggregate function. The OVER clause determines
exactly how the rows of the query are split up for processing by the window function.
• The PARTITION BY list within OVER specifies dividing the rows into groups, or partitions, that share the same values of the
PARTITION BY expression(s). For each row, the window function is computed across the rows that fall into the same
partition as the current row.

Inheritance
• Inheritance is a concept from object-oriented databases. It opens up interesting new possibilities of database design.
Example:
- CREATE TABLE parents(
p_id int,
name varchar(30)
)
- CREATE TABLE children(
c_id int,
name varchar(30)
) inherits (parents);
Note: Although inheritance is frequently useful, it has not been integrated with unique constraints or foreign keys, which
limits its usefulness.

Value Expressions
• Value expressions are used in a variety of contexts, such as in the target list of the SELECT command, as new column values in INSERT or UPDATE,
or in search conditions in a number of commands. The result of a value expression is sometimes called a scalar, to distinguish it from the result of
a table expression (which is a table). Value expressions are therefore also called scalar expressions (or even simply expressions). The expression
syntax allows the calculation of values from primitive parts using arithmetic, logical, set, and other operations.
A value expression is one of the following:
- A constant or literal value
- A column reference
- A positional parameter reference, in the body of a function definition or prepared statement
- A subscripted expression
- A field selection expression
- An operator invocation
- A function call
- An aggregate expression
- A window function call
- A type cast
- A collation expression
- A scalar subquery
- An array constructor
- A row constructor

Type Casts
• A type cast specifies a conversion from one data type to another.
• PostgreSQL accepts two equivalent syntaxes for type casts:
1. Using CAST keyword:
Ex: SELECT CAST(field_name AS TYPE) FROM table_name;
2. Using Symbol (::):
Ex: SELECT field_name::TYPE FROM table_name;

Scalar Subqueries
• A scalar subquery is an ordinary SELECT query in parentheses that returns exactly one row with one column.
• The SELECT query is executed and the single returned value is used in the surrounding value expression.
• It is an error to use a query that returns more than one row or more than one column as a scalar subquery.
• The subquery can refer to variables from the surrounding query, which will act as constants during any one evaluation of the
subquery.
Ex: SELECT field_name, (SELECT fiel_name FROM table_name2 WHERE
table_name2.field_name=table_name1.field_name) FROM table_name1;

Calling Function
• PostgreSQL allows functions that have named parameters to be called using either positional or named notation.
• Named notation is especially useful for functions that have a large number of parameters, since it makes the associations
between parameters and actual arguments more explicit and reliable. In named notation, the arguments are matched to the
function parameters by name and can be written in any order.
• In positional notation, a function call is written with its argument values in the same order as they are defined in the function
declaration.
Ex: CREATE FUNCTION concat_lower_or_upper(a text, b text, uppercase boolean DEFAULT false) RETURNS text AS $$
SELECT CASE
WHEN $3 THEN UPPER($1 || ' ' || $2)
ELSE LOWER($1 || ' ' || $2)
END;
$$ LANGUAGE SQL IMMUTABLE STRICT;
- Using Positional Notation: SELECT concat_lower_or_upper('Hello', 'World', true); or SELECT concat_lower_or_upper('Hello',
'World');
- Using Named Notation: SELECT concat_lower_or_upper(a := 'Hello', b := 'World'); Or SELECT concat_lower_or_upper(a :=
'Hello', b := 'World', uppercase := true); OR SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
- Using mix: SELECT concat_lower_or_upper('Hello', 'World', uppercase := true);

Default Values
• A data manipulation command can also request explicitly that a column be set to its default value, without having to know
what that value is.
• If no default value is declared explicitly, the default value is the null value. This usually makes sense because a null value
can be considered to represent unknown data.
Example:
CREATE TABLE products (
pro_no integer primary key,
name text,
price numeric DEFAULT 9.99
);

Constraints
• Constraints give you as much control over the data in your tables as you wish.
• A check constraint is the most generic constraint type. It allows you to specify that the value in a certain column must satisfy a
Boolean (truth-value) expression.
Ex: CREATE TABLE products (pro_no integer, name text, price numeric CHECK (price > 0));
• A not-null constraint simply specifies that a column must not assume the null value.
Ex: CREATE TABLE products (pro_no integer NOT NULL, name text NOT NULL, price numeric);
• Unique constraints ensure that the data contained in a column or a group of columns is unique with respect to all the rows in
the table.
Ex: CREATE TABLE products (pro_no integer UNIQUE, name text, price numeric);
• A primary key constraint is simply a combination of a unique constraint and a not-null constraint.
Ex: CREATE TABLE products (pro_no integer PRIMARY KEY, name text, price numeric);
• A foreign key constraint specifies that the values in a column (or a group of columns) must match the values appearing in some
row of another table. We say this maintains the referential integrity between two related tables.
Ex: CREATE TABLE orders (order_id integer PRIMARY KEY, pro_no integer REFERENCES products (pro_no), quantity integer);
• Exclusion constraints ensure that if any two rows are compared on the specified columns or expressions using the specified
operators, at least one of these operator comparisons will return false or null.
Ex: CREATE TABLE circles ( c circle, EXCLUDE USING gist (c WITH &&) );

System Columns
• Every table has several system columns that are implicitly defined by the system. Therefore, these names cannot be used
as names of user-defined columns.
• oid: The object identifier (object ID) of a row. This column is only present if the table was created using WITH OIDS, or if
the default_with_oids configuration variable was set at the time.
• tableoid: The OID of the table containing this row. This column is particularly handy for queries that select from
inheritance hierarchies.
• xmin: The identity (transaction ID) of the inserting transaction for this row version. (A row version is an individual state of
a row; each update of a row creates a new row version for the same logical row.).
• cmin: The command identifier (starting at zero) within the inserting transaction.
• xmax: The identity (transaction ID) of the deleting transaction, or zero for an undeleted row version. It is possible for this
column to be nonzero in a visible row version. That usually indicates that the deleting transaction hasn't committed yet, or
that an attempted deletion was rolled back.
• cmax: The command identifier within the deleting transaction, or zero.
• ctid: The ctid can be used to locate the row version very quickly, a row's ctid will change if it is updated or moved by
VACUUM FULL. Therefore ctid is useless as a long-term row identifier. The OID, or even better a user-defined serial
number, should be used to identify logical rows.

Modifying Tables
• PostgreSQL provides a family of commands to make modifications to existing tables.
We can do:
- Add columns: Ex: ALTER TABLE products ADD COLUMN description text;
- Removing a Column: Ex: ALTER TABLE products DROP COLUMN description;
- Adding a Constraint: Ex: ALTER TABLE products ADD CHECK (name <> '');
ALTER TABLE products ADD CONSTRAINT some_name UNIQUE (pro_no);
ALTER TABLE products ADD FOREIGN KEY (pro_group_id) REFERENCES product_groups;
- Removing a Constraint: Ex: ALTER TABLE products DROP CONSTRAINT some_name;
- Changing a Column's Default Value: Ex: ALTER TABLE products ALTER COLUMN price SET DEFAULT 7.77;
- Changing a Column's Data Type: Ex: ALTER TABLE products ALTER COLUMN price TYPE numeric(10,2);
- Renaming a Column: Ex: ALTER TABLE products RENAME COLUMN product_no TO product_number;
- Renaming a Table: Ex: ALTER TABLE products RENAME TO items;

Privileges
• There are different kinds of privileges: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE,
CONNECT, TEMPORARY, EXECUTE, and USAGE.
• To assign privileges:
Ex:
GRANT UPDATE ON table_name TO user_name;
GRANT ALL PRIVILEGES ON table_name TO user_name;
• To revoke a privilege:
Ex:
REVOKE ALL ON table_name FROM PUBLIC;

Schemas
• A database contains one or more named schemas, which in turn contain tables.
• There are several reasons why one might want to use schemas:
- To allow many users to use one database without interfering with each other.
- To organize database objects into logical groups to make them more manageable.
- Third-party applications can be put into separate schemas so they do not collide with the names of other objects.
• To create a schema: Ex: CREATE SCHEMA schema_name;
• The Schema Search Path
- To show the current search path: Ex: SHOW search_path;
- To put our new schema in the path: Ex: SET search_path TO myschema,public;

Partitioning
• Partitioning refers to splitting what is logically one large table into smaller physical pieces.
• Partitioning can provide several benefits:
- Query performance can be improved dramatically in certain situations, particularly when most of the heavily
accessed rows of the table are in a single partition or a small number of partitions. The partitioning substitutes for leading
columns of indexes, reducing index size and making it more likely that the heavily-used parts of the indexes fit in memory.
- When queries or updates access a large percentage of a single partition, performance can be improved by taking
advantage of sequential scan of that partition instead of using an index and random access reads scattered across the whole
table.
- Bulk loads and deletes can be accomplished by adding or removing partitions, if that requirement is planned into
the partitioning design. ALTER TABLE NO INHERIT and DROP TABLE are both far faster than a bulk operation. These
commands also entirely avoid the VACUUM overhead caused by a bulk DELETE.
- Seldom-used data can be migrated to cheaper and slower storage media.
• The following forms of partitioning can be implemented in PostgreSQL:
- Range Partitioning: The table is partitioned into "ranges" defined by a key column or set of columns, with no
overlap between the ranges of values assigned to different partitions. For example one might partition by date ranges, or by
ranges of identifiers for particular business objects.
- List Partitioning: The table is partitioned by explicitly listing which key values appear in each partition.

Foreign Data
• PostgreSQL implements portions of the SQL/MED specification, allowing you to access data that resides outside
PostgreSQL using regular SQL queries.
• Foreign data is accessed with help from a foreign data wrapper.
• A foreign data wrapper is a library that can communicate with an external data source, hiding the details of connecting to
the data source and obtaining data from it.
• To access foreign data, you need to create a foreign server object, which defines how to connect to a particular external
data source according to the set of options used by its supporting foreign data wrapper. Then you need to create one or
more foreign tables, which define the structure of the remote data.
• A foreign table can be used in queries just like a normal table, but a foreign table has no storage in the PostgreSQL server.

Table Expressions
• The table expression contains a FROM clause that is optionally followed by WHERE, GROUP BY, and HAVING clauses.
• Join Types:
- Cross join: Ex: T1 CROSS JOIN T2
- Qualified joins:
Ex:
- T1 { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2 ON boolean_expression
- T1 { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2 USING ( join column list )
- T1 NATURAL { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2
• The possible types of qualified join are:
- INNER JOIN: For each row R1 of T1, the joined table has a row for each row in T2 that satisfies the join condition
with R1.
- LEFT OUTER JOIN: First, an inner join is performed. Then, for each row in T1 that does not satisfy the join
condition with any row in T2, a joined row is added with null values in columns of T2.
- RIGHT OUTER JOIN: First, an inner join is performed. Then, for each row in T2 that does not satisfy the join
- FULL OUTER JOIN: First, an inner join is performed. Then, for each row in T1 that does not satisfy the join

Table Functions
• Table functions are functions that produce a set of rows, made up of either base data types (scalar types) or composite data
types (table rows).
• They are used like a table, view, or subquery in the FROM clause of a query.
• Columns returned by table functions can be included in SELECT, JOIN, or WHERE clauses in the same manner as columns of a
table, view, or subquery.
Example:
-CREATE TABLE foo (fooid int, foosubid int, fooname text);
- CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$ SELECT * FROM foo WHERE fooid = $1; $$ LANGUAGE SQL;
- SELECT * FROM getfoo(1) AS t1;
- SELECT * FROM foo WHERE foosubid IN (SELECT foosubid FROM getfoo(foo.fooid) z WHERE z.fooid = foo.fooid);
- CREATE VIEW vw_getfoo AS SELECT * FROM getfoo(1);
-SELECT * FROM vw_getfoo;

LATERAL Subqueries
• A LATERAL item can appear at top level in the FROM list, or within a JOIN tree. In the latter case it can also refer to any
items that are on the left-hand side of a JOIN that it is on the right-hand side of.
• A trivial example of LATERAL is:
Example: SELECT * FROM foo, LATERAL (SELECT * FROM bar WHERE bar.id = foo.bar_id) ss;
• LATERAL is primarily useful when the cross-referenced column is necessary for computing the row(s) to be joined. A
common application is providing an argument value for a set-returning function.
Example:
- SELECT p1.id, p2.id, v1, v2 FROM polygons p1 CROSS JOIN LATERAL vertices(p1.poly) v1, polygons p2 CROSS JOIN
LATERAL vertices(p2.poly) v2 WHERE (v1 <-> v2) < 10 AND p1.id != p2.id;

LIMIT and OFFSET
• LIMIT and OFFSET allow you to retrieve just a portion of the rows that are generated by the rest of the query:
Syntax:
SELECT select_list FROM table_expression [ ORDER BY ... ] [ LIMIT { number | ALL } ] [ OFFSET number ]
• OFFSET says to skip that many rows before beginning to return rows.
• OFFSET 0 is the same as omitting the OFFSET clause, and LIMIT NULL is the same as omitting the LIMIT clause.
• If both OFFSET and LIMIT appear, then OFFSET rows are skipped before starting to count the LIMIT rows that are returned.

WITH Queries (Common Table Expressions)
• WITH provides a way to write auxiliary statements for use in a larger query.
• Each auxiliary statement in a WITH clause can be a SELECT, INSERT, UPDATE, or DELETE; and the WITH clause itself is
attached to a primary statement that can also be a SELECT, INSERT, UPDATE, or DELETE.
• Recursive Query Evaluation:
1- Evaluate the non-recursive term. For UNION (but not UNION ALL), discard duplicate rows. Include all remaining
rows in the result of the recursive query, and also place them in a temporary working table.
2- So long as the working table is not empty, repeat these steps:
- Evaluate the recursive term, substituting the current contents of the working table for the recursive
self-reference. For UNION (but not UNION ALL), discard duplicate rows and rows that duplicate any previous result row.
Include all remaining rows in the result of the recursive query, and also place them in a temporary intermediate table.
- Replace the contents of the working table with the contents of the intermediate table, then empty
the intermediate table.

Monetary Types
• The money type stores a currency amount with a fixed fractional precision.
• Conversion from the real and double precision data types can be done by casting to numeric first:
Example:
- SELECT '12.34'::float8::numeric::money;
• Conversion to other types could potentially lose precision, and must also be done in two stages:
Example:
- SELECT '52093.89'::money::numeric::float8;

Character Types
Special Character Types

Binary Data Types
• The bytea data type allows storage of binary strings.
• A binary string is a sequence of octets (or bytes).
• bytea Literal Escaped Octets:
• bytea Output Escaped Octets:

ISO 8601 Interval Unit Abbreviations

Enumerated Types
• Enumerated (enum) types are data types that comprise a static, ordered set of values.
• Declaration of Enumerated Types:
Example:
- CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');
- CREATE TABLE person (
name text,
current_mood mood
);
- INSERT INTO person VALUES ('Moe', 'happy');
- SELECT * FROM person WHERE current_mood = 'happy';

Geometric Types
• Geometric data types represent two-dimensional spatial objects.

Network Address Types
• The inet type holds an IPv4 or IPv6 host address, and optionally its subnet, all in one field. The subnet is represented by
the number of network address bits present in the host address (the "netmask").
• The cidr type holds an IPv4 or IPv6 network specification. Input and output formats follow Classless Internet Domain
Routing conventions. The format for specifying networks is address/y where address is the network represented as an IPv4
or IPv6 address, and y is the number of bits in the netmask.
• The macaddr type stores MAC addresses, known for example from Ethernet card hardware addresses (although MAC
addresses are used for other purposes as well).

Bit String Types
• Bit strings are strings of 1's and 0's.
• There are two SQL bit types: bit(n) and bit varying(n), where n is a positive integer.
• bit type data must match the length n exactly; it is an error to attempt to store shorter or longer bit strings.
• bit varying data is of variable length up to the maximum length n; longer strings will be rejected.
• Using the Bit String Types:
Example:
- CREATE TABLE test (a BIT(3), b BIT VARYING(5));
- INSERT INTO test VALUES (B'101', B'00');
- INSERT INTO test VALUES (B'10', B'101');
ERROR: bit string length 2 does not match type bit(3)
- INSERT INTO test VALUES (B'10'::bit(3), B'101');
- SELECT * FROM test;

Text Search Types
• PostgreSQL provides two data types that are designed to support full text search are tsvector and tsquery.
• A tsvector value is a sorted list of distinct lexemes, which are words that have been normalized to merge different variants
of the same word.
Example: SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector;
• Raw document text should usually be passed through to_tsvector to normalize the words appropriately for searching:
Example: SELECT to_tsvector('english', 'The Fat Rats');
• A tsquery value stores lexemes that are to be searched for, and combines them honoring the Boolean operators & (AND),
| (OR), and ! (NOT).
Example: SELECT 'fat & rat'::tsquery;
• The to_tsquery function is convenient for performing such normalization:
Example: SELECT to_tsquery('Fat:ab & Cats');

UUID Type
• The data type uuid stores Universally Unique Identifiers (UUID) as defined by RFC 4122, ISO/IEC 9834-8:2005, and related
standards.
• This identifier is a 128-bit quantity that is generated by an algorithm chosen to make it very unlikely that the same
identifier will be generated by anyone else in the known universe using the same algorithm.
• A UUID is written as a sequence of lower-case hexadecimal digits, in several groups separated by hyphens, specifically a
group of 8 digits followed by three groups of 4 digits followed by a group of 12 digits, for a total of 32 digits representing
the 128 bits.
• An example of a UUID in this standard form is:
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11

XML Type
• The xml data type can be used to store XML data.
• Its advantage over storing XML data in a text field is that it checks the input values for well-formedness, and there are
support functions to perform type-safe operations on it.
• To produce a value of type xml from character data, use the function xmlparse:
Syntax: XMLPARSE ( { DOCUMENT | CONTENT } value)
Examples:
XMLPARSE (DOCUMENT '<?xml version="1.0"?><book><title>Manual</title><chapter>...</chapter></book>')
• The inverse operation, producing a character string value from xml, uses the function xmlserialize:
Syntax: XMLSERIALIZE ( { DOCUMENT | CONTENT } value AS type )
• When a character string value is cast to or from type xml without going through XMLPARSE or XMLSERIALIZE, respectively,
the choice of DOCUMENT versus CONTENT is determined by the "XML option" session configuration parameter, which can
be set using the standard command:
Syntax: SET XML OPTION { DOCUMENT | CONTENT };
Ex: SET xmloption TO { DOCUMENT | CONTENT };

JSON Types
• JSON data types are for storing JSON (JavaScript Object Notation) data.
• here are two JSON data types: json and jsonb.
• The json data type stores an exact copy of the input text, which processing functions must reparse on each execution.
• The jsonb data is stored in a decomposed binary format that makes it slightly slower to input due to added conversion
overhead, but significantly faster to process, since no reparsing is needed.
• JSON primitive types and corresponding PostgreSQL types:

Arrays
• An array data type is named by appending square brackets ([]) to the data type name of the array elements.
• To illustrate the use of array types, we create this table:
Ex: CREATE TABLE table_arry(id integer, name text, pay_by_quarter [], schedule text [][]);
• To set an element of an array constant to NULL, write NULL for the element value. (Any upper- or lower-case variant of
NULL will do.) If you want an actual string value "NULL", you must put double quotes around it.

Composite Types
• A composite type represents the structure of a row or record; it is essentially just a list of field names and their data types.
Syntax:
- CREATE TYPE composite_name AS ( r double precision, I double precision);
- CREATE TYPE inventory_item AS (name text, supplier_id integer, price numeric);
- CREATE TABLE on_hand (item inventory_item, count integer);
- INSERT INTO on_hand VALUES (ROW('fuzzy dice', 42, 1.99), 1000);
• To access a field of a composite column, one writes a dot and the field name, much like selecting a field from a table name.
Example: SELECT item.name FROM on_hand WHERE item.price > 9.99;

Range Types
• Range types are data types representing a range of values of some element type (called the range's subtype).
• For instance, ranges of timestamp might be used to represent the ranges of time that a meeting room is reserved. In this
case the data type is tsrange (short for "timestamp range"), and timestamp is the subtype.
• The subtype must have a total order so that it is well-defined whether element values are within, before, or after a range
of values.
• Range types are useful because they represent many element values in a single range value, and because concepts such as
overlapping ranges can be expressed clearly.
• The following built-in range types:
- int4range — Range of integer
- int8range — Range of bigint
- numrange — Range of numeric
- tsrange — Range of timestamp without time zone
- tstzrange — Range of timestamp with time zone
- daterange — Range of date

Object Identifier Types
• Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables.
• Type oid represents an object identifier.
• There are also several alias types for oid: regproc, regprocedure, regoper, regoperator, regclass, regtype, regconfig, and
regdictionary.

pg_lsn Type
• The pg_lsn data type can be used to store LSN (Log Sequence Number) data which is a pointer to a location in the XLOG.
• This type is a representation of XLogRecPtr and an internal system type of PostgreSQL.
• An LSN is a 64-bit integer, representing a byte position in the write-ahead log stream.
• The pg_lsn type supports the standard comparison operators, like = and >.
• Two LSNs can be subtracted using the - operator; the result is the number of bytes separating those write-ahead log
positions.

Pseudo-Types
• A pseudo-type cannot be used as a column data type, but it can be used to declare a function's argument or result type.

String Functions and Operators

Bit String Functions and Operators

Data Type Formatting Functions

Enum Support Functions
• There are several functions that allow cleaner programming without hard-coding particular values of an enum type.
Example:
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');

Geometric Type Conversion Functions

Text Search Debugging Functions

Sequence Manipulation Functions
• nextval: Advance the sequence object to its next value and return that value. This is done atomically: even if multiple
sessions execute nextval concurrently, each will safely receive a distinct sequence value.
• currval: Return the value most recently obtained by nextval for this sequence in the current session. (An error is reported
if nextval has never been called for this sequence in this session.) Because this is returning a session-local value, it gives a
predictable answer whether or not other sessions have executed nextval since the current session did.
• lastval: Return the value most recently returned by nextval in the current session. This function is identical to currval,
except that instead of taking the sequence name as an argument it fetches the value of the last sequence used by nextval
in the current session. It is an error to call lastval if nextval has not yet been called in the current session.
• setval:Reset the sequence object's counter value. The two-parameter form sets the sequence's last_value field to the
specified value and sets its is_called field to true, meaning that the next nextval will advance the sequence before
returning a value. The value reported by currval is also set to the specified value. In the three-parameter form, is_called
can be set to either true or false. true has the same effect as the two-parameter form. If it is set to false, the next nextval
will return exactly the specified value, and sequence advancement commences with the following nextval.

COALESCE & NULLIF
• The COALESCE function returns the first of its arguments that is not null.
• Null is returned only if all arguments are null.
Example:
SELECT COALESCE(description, short_description, '(none)') ...
* This returns description if it is not null, otherwise short_description if it is not null, otherwise (none).
• The NULLIF function returns a null value if value1 equals value2; otherwise it returns value1.
Example:
SELECT NULLIF(value, '(none)') ...

GREATEST and LEAST
• The GREATEST and LEAST functions select the largest or smallest value from a list of any number of expressions.
• The expressions must all be convertible to a common data type, which will be the type of the result
Syntax:
- GREATEST(value [, ...])
- LEAST(value [, ...])
Note that GREATEST and LEAST are not in the SQL standard, but are a common extension. Some other databases make them
return NULL if any argument is NULL, rather than only when all are NULL.

Aggregate Functions for Statistics

Ordered-Set Aggregate Functions

Hypothetical-Set Aggregate Functions

Subquery Expressions
• The argument of EXISTS is an arbitrary SELECT statement, or subquery. The subquery is evaluated to determine whether it
returns any rows. If it returns at least one row, the result of EXISTS is "true"; if the subquery returns no rows, the result of
EXISTS is "false".
Example: SELECT col1 FROM tab1 WHERE EXISTS (SELECT 1 FROM tab2 WHERE col2 = tab1.col2);

System Administration Functions
• Configuration Settings Functions
• Ex:
-SELECT current_setting('datestyle');
- SELECT set_config('log_statement_stats', 'off', false);

Snapshot Synchronization Functions
• A snapshot determines which data is visible to the transaction that is using the snapshot.
• Synchronized snapshots are necessary when two or more sessions need to see identical content in the database.
• The function pg_export_snapshot saves the current snapshot and returns a text string identifying the snapshot.

Index
• Indexes are a common way to enhance database performance.
• An index allows the database server to find and retrieve specific rows much faster than it could do without an index.
• To create index we use as below:
Syntax:
CREATE INDEX index_name ON table_name (filename);
Ex:
CREATE INDEX table_id_index ON table(id);
• But you might have to run the ANALYZE command regularly to update statistics to allow the query planner to make
educated decisions.

Index Types
• Index types: B-tree, Hash, GiST, SP-GiST and GIN. Each index type uses a different algorithm that is best suited to different
types of queries.
• By default, the CREATE INDEX command creates B-tree indexes, which fit the most common situations.
• B-trees can handle equality and range queries on data that can be sorted into some ordering.
• Hash indexes can only handle simple equality comparisons. Ex: CREATE INDEX name ON table USING hash (column);
• GiST indexes are not a single kind of index, but rather an infrastructure within which many different indexing strategies can
be implemented.
• GIN indexes are inverted indexes which can handle values that contain more than one key, arrays for example. Like GiST
and SP-GiST, GIN can support many different user-defined indexing strategies and the particular operators with which a
GIN index can be used vary depending on the indexing strategy.

Multicolumn Indexes
• An index can be defined on more than one column of a table. Ex: CREATE INDEX test2_mm_idx ON test2 (major, minor);
• A multicolumn B-tree index can be used with query conditions that involve any subset of the index's columns, but the
index is most efficient when there are constraints on the leading (leftmost) columns.
• A multicolumn GiST index can be used with query conditions that involve any subset of the index's columns.
• A multicolumn GIN index can be used with query conditions that involve any subset of the index's columns.

Full Text Search
• To provides the capability to identify natural-language documents that satisfy a query, and optionally to sort them by
relevance to the query.
• Full text indexing allows documents to be preprocessed and an index saved for later rapid searching. Preprocessing
includes:
- Parsing documents into tokens. It is useful to identify various classes of tokens, e.g., numbers, words, complex
words, email addresses, so that they can be processed differently.
- Converting tokens into lexemes. A lexeme is a string, just like a token, but it has been normalized so that
different forms of the same word are made alike.
- Storing preprocessed documents optimized for searching. For example, each document can be represented as a
sorted array of normalized lexemes. Along with the lexemes it is often desirable to store positional information to use for
proximity ranking, so that a document that contains a more "dense" region of query words is assigned a higher rank than one
with scattered query words.

Concurrency Control
• Data consistency is maintained by using a multiversion model (Multiversion Concurrency Control, MVCC).
• The main advantage of using the MVCC model of concurrency control rather than locking is that in MVCC locks acquired for querying
(reading) data do not conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading.

Transaction Isolation
• The phenomena which are prohibited at various levels are:
- dirty read
A transaction reads data written by a concurrent uncommitted transaction.
- nonrepeatable read
A transaction re-reads data it has previously read and finds that data has been modified by another
transaction (that committed since the initial read).
- phantom read
A transaction re-executes a query returning a set of rows that satisfy a search condition and finds that
the set of rows satisfying the condition has changed due to another recently-committed transaction.

Explicit Locking
• ACCESS EXCLUSIVE lock cannot be held by more than one transaction at a time (self-conflicting).
• ACCESS SHARE lock can be held by multiple transactions (not self-conflicting).
Table-level Locks:

Row-level Locks
• Can be exclusive or shared locks.
• They block only writers to the same row.
• Locking a row might cause a disk write, e.g., SELECT FOR UPDATE modifies selected rows to mark them locked, and so will
result in disk writes.

Deadlocks
• Deadlock occurs when transaction 2 has already exclusive-locked table B and now wants an exclusive lock on table A.
• Deadlocks can also occur as the result of row-level locks (and thus, they can occur even if explicit locking is not used).
• The best defense against deadlocks is generally to avoid them by being certain that all applications using a database
acquire locks on multiple objects in a consistent order.
• So long as no deadlock situation is detected, a transaction seeking either a table-level or row-level lock will wait
indefinitely for conflicting locks to be released. This means it is a bad idea for applications to hold transactions open for
long periods of time (e.g., while waiting for user input).

Advisory Locks
• Advisory locks can be useful for locking strategies that are an awkward fit for the MVCC model.
• There are two ways to acquire an advisory lock in PostgreSQL:
1. At session level or at transaction level. Once acquired at session level, an advisory lock is held until explicitly
released or the session ends.
2. Transaction-level lock requests, on the other hand, behave more like regular lock requests: they are
automatically released at the end of the transaction, and there is no explicit unlock operation.

Data Consistency Checks at the Application Level
• Enforcing Consistency With Serializable Transactions:
When using this technique, it will avoid creating an unnecessary burden for application programmers if the
application software goes through a framework which automatically retries transactions which are rolled back
with a serialization failure. It may be a good idea to set default_transaction_isolation to serializable. It would also
be wise to take some action to ensure that no other transaction isolation level is used, either inadvertently or to
subvert integrity checks, through checks of the transaction isolation level in triggers.
• Enforcing Consistency With Explicit Blocking Locks:
Non-serializable writes are possible, to ensure the current validity of a row and protect it against concurrent
updates one must use SELECT FOR UPDATE, SELECT FOR SHARE, or an appropriate LOCK TABLE statement. (SELECT
FOR UPDATE and SELECT FOR SHARE lock just the returned rows against concurrent updates, while LOCK TABLE
locks the whole table.).

Locking and Indexes
• B-tree, GiST and SP-GiST indexes:
Short-term share/exclusive page-level locks are used for read/write access. Locks are released immediately after
each index row is fetched or inserted. These index types provide the highest concurrency without deadlock
conditions.
• Hash indexes:
Share/exclusive hash-bucket-level locks are used for read/write access. Locks are released after the whole bucket
is processed. Bucket-level locks provide better concurrency than index-level ones, but deadlock is possible since
the locks are held longer than one index operation.
• GIN indexes:
Short-term share/exclusive page-level locks are used for read/write access. Locks are released immediately after
each index row is fetched or inserted. But note that insertion of a GIN-indexed value usually produces several
index key insertions per row, so GIN might do substantial work for a single value's insertion.

Performance Tips
• EXPLAIN
• EXPLAIN ANALYZE

Populating a Database
• Disable Autocommit
• Use COPY
• Remove Indexes
• Remove Foreign Key Constraints
• Increase maintenance_work_mem
• Increase checkpoint_segments
• Disable WAL Archival and Streaming Replication:
To prevent incremental WAL logging while loading, disable archiving and streaming replication, by setting
wal_level to minimal, archive_mode to off, and max_wal_senders to zero. But note that changing these settings
requires a server restart.
• Run ANALYZE Afterwards
• Some Notes About pg_dump

Non-Durable Settings
• Durability is a database feature that guarantees the recording of committed transactions even if the server crashes or
loses power.
• Place the database cluster's data directory in a memory-backed file system (i.e. RAM disk). This eliminates all database disk
I/O, but limits data storage to the amount of available memory (and perhaps swap).
• Turn off fsync; there is no need to flush data to disk.
• Turn off synchronous_commit; there might be no need to force WAL writes to disk on every commit. This setting does risk
transaction loss (though not data corruption) in case of a crash of the database.
• Turn off full_page_writes; there is no need to guard against partial page writes.
• Increase checkpoint_segments and checkpoint_timeout ; this reduces the frequency of checkpoints, but increases the
storage requirements of /pg_xlog.
• Create unlogged tables to avoid WAL writes, though it makes the tables non-crash-safe

Installation from Source Code
• Short Version:
./configure
make
su
make install
adduser postgres
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data
su - postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data >logfile 2>&1 &
/usr/local/pgsql/bin/createdb test
/usr/local/pgsql/bin/psql test

PostgreSQL Database Slides

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to PostgreSQL Database Slides (20)

Recently uploaded (20)

PostgreSQL Database Slides