In this post, I am sharing a script for getting the list of objects of a particular User (Owner of the Object) in PostgreSQL.
Generally, PostgreSQL DBAs are using this kind of script for auditing purpose and object tracking purpose.

Using the below script, you can get the list object for a particular user:

I used a ‘postgres’ default user in WHERE condition, which you can edit as per your user.

select 
    nsp.nspname as SchemaName
    ,cls.relname as ObjectName 
    ,rol.rolname as ObjectOwner
    ,case cls.relkind
        when 'r' then 'TABLE'
        when 'm' then 'MATERIALIZED_VIEW'
        when 'i' then 'INDEX'
        when 'S' then 'SEQUENCE'
        when 'v' then 'VIEW'
        when 'c' then 'TYPE'
        else cls.relkind::text
    end as ObjectType
from pg_class cls
join pg_roles rol 
	on rol.oid = cls.relowner
join pg_namespace nsp 
	on nsp.oid = cls.relnamespace
where nsp.nspname not in ('information_schema', 'pg_catalog')
    and nsp.nspname not like 'pg_toast%'
    and rol.rolname = 'postgres'  
order by nsp.nspname, cls.relname

If you don’t know about the TOAST Table, please visit the below article.

PostgreSQL: What is TOAST (The Oversized-Attribute Storage Technique)

In this post, I am sharing a script to check the used space by the TOAST tables in the PostgreSQL.

We should avoid the auto-creation of TOAST table which is not suitable for database performance.
Using below script, you can find the size and can take the appropriate decision on the biggest TOAST table of your database.

Below script is returning two columns where relpages is a number of occupied pages by the TOAST table. (1 page = 8kb)

SELECT 
    relname
    ,relpages
FROM pg_class,
     (SELECT reltoastrelid
      FROM pg_class) AS ss
WHERE oid = ss.reltoastrelid OR
      oid = (SELECT indexrelid
             FROM pg_index
             WHERE indrelid = ss.reltoastrelid)
ORDER BY relname;

In this post, I am sharing a quick way to move your table with data from one schema to another schema of PostgreSQL.

I already shared an article on, how to copy a table from one schema to another schema.

PostgreSQL: Script to copy Table Data from one Schema to another Schema

For moving the table between the schemas is a very simple, you should just update the entry in pg_class and pg_type table.
Something like update the table schema name from old to the new basis on given table name.

Please check the below solution, try it your self:

UPDATE pg_catalog.pg_class
SET relnamespace = (SELECT oid FROM pg_catalog.pg_namespace
                    WHERE nspname = 'destination_schema')
WHERE relnamespace = (SELECT oid FROM pg_catalog.pg_namespace
                      WHERE nspname = 'source_schema')
AND relname = 'table_name';

UPDATE pg_catalog.pg_type
SET typnamespace = (SELECT oid FROM pg_catalog.pg_namespace
                    WHERE nspname = 'destination_schema')
WHERE typnamespace = (SELECT oid FROM pg_catalog.pg_namespace
                      WHERE nspname = 'source_schema')
AND typname = 'table_name';

In this post, I am sharing a script to find orphaned Sequence objects which not owned by any column of PostgreSQL Database.

When we define a column using SERIAL or BIGSERIAL, PostgreSQL internally creates one sequence for it and associate with it.
In RDBMS, A Sequence is an independent object, and you can use same sequence object for multiple tables as well.

In a development environment, we are executing DDL frequently commands like multiple CREATE or DROP statements, so there is possibility of Orphaned Sequence.

A Database Administrator can use this script to remove unwanted Sequence and make sure that Postgres database is up to date.

SELECT 
	ns.nspname AS SchemaName
	,c.relname AS SequenceName
FROM pg_class AS c
JOIN pg_namespace AS ns 
	ON c.relnamespace=ns.oid
WHERE c.relkind = 'S'
  AND NOT EXISTS (SELECT * FROM pg_depend WHERE objid=c.oid AND deptype='a')
ORDER BY c.relname;

This is one of the very important post for all PostgreSQL Database Professionals.

In this post, I am sharing a small, but very powerful script to know about the Live Tuples (Rows) and Dead Tuples (Rows) of the PostgreSQL Object like: Tables and Indexes.

If you don’t know about the MVCC (Multi Version Concurrency Control), Please visit this article.

What is Multi Version Concurrency Control (MVCC)

PostgreSQL is based on MVCC Architecture.

In MVCC Architecture, When you update or delete any row, Internally It creates the new row and mark old row as unused.

This kind of data, we call as Dead Tuples or Dead Rows. (We can also say like, This is an internal fragmentation).

Periodically, We should find dead rows of the object and we should remove it using VACUUM techniques of PostgreSQL.
By this way, we can increase the overall performance of PostgreSQL Database Server.

PostgreSQL: Short note on VACUUM, VACUUM FULL and ANALYZE

Find out Live Tuples or Dead Tuples using two different scripts.

Using system function and pg_class:

SELECT 
	relname AS ObjectName
	,pg_stat_get_live_tuples(c.oid) AS LiveTuples
	,pg_stat_get_dead_tuples(c.oid) AS DeadTuples
FROM pg_class c;

Using pg_stat_user_tables:

SELECT 
	relname AS TableName
	,n_live_tup AS LiveTuples
	,n_dead_tup AS DeadTuples
FROM pg_stat_user_tables;

In this post, I am sharing one script to find information about the Locks which are held by Open Transactions of PostgreSQL Database Server.

Database Theory: What is Timeout, Lock, Block, and Deadlock in a Database System?

PostgreSQL view pg_locks contains the main information about the all types of lock of Database Server.
It contains one row per active lockable object.

This script is very helpful to all PostgreSQL Database Administrators.

Below is a script:

SELECT 
	pl.pid AS ProcessID
	,psa.datname AS DatabaseName
	,psa.usename AS UserName
	,psa.application_name AS ApplicationName
	,ps.relname AS ObjectName
	,psa.query_start AS QueryStartTime
	,psa.state AS QueryState
	,psa.query AS SQLQuery
	,pl.locktype
	,pl.tuple AS TupleNumber
	,pl.mode AS LockMode
	,pl.granted -- True if lock is held, false if lock is awaited
FROM pg_locks AS pl 
LEFT JOIN pg_stat_activity AS psa
	ON pl.pid = psa.pid
LEFT JOIN pg_class AS ps
	ON pl.relation = ps.oid

In any RDBMS system, Different type of Statistics is very important for Query Optimizer and Planner to choose and generate the best Query Execution Plan.

PostgreSQL Database Server also managing different types of Statistic which are used by the Query Optimizer to generate the best Query Execution Plan.

Statistical data should be updated, Why?
For Example,

We have one table with 100000 rows, but table statistic data are not updated and showing only 1000 tuples information.

Query optimizer always looks into Statistic tables, It never looks into direct table files.

So in this situation, It generates the wrong Query Execution Plan because It has only 1000 rows information, but actually there are 100000 rows.

PostgreSQL Database Server is mainly using two Statistical Table.

SELECT *FROM pg_class;
SELECT *FROM pg_stats;

You can also query these tables and can find information about Tables, Indexes, Pages and others.

When you look into table pg_class, you can find “reltuples” column. You can compare this column value with your actual table record count.

If you find any mismatch, for that table statistic information is not updated.

Execute Analyze command:

When you find that Statistical information is not updated, you can execute the ANALYZE command on the Database or Table.
After executing the ANALYZE command, It updates all require statistics.

PostgreSQL: Short note on VACUUM, VACUUM FULL and ANALYZE

If a table has a 5000 or 500000 or 5000000000 records and the requirement is to find the total row count of the table, most of the Database Developer always executes COUNT(*) for getting the row count.

I found that many of our team members also execute COUNT(*), but just imagine that table has 5000000000 rows and COUNT(*) is taking a long time for getting the number of records.

The counting of the rows in such a big table always creates the performance issue and its also required I/O operation.

If you need exact row count for a given time, COUNT(*) is mandatory.
But you can speed up this dramatically if the count does not have to be exact.
You can use a metadata table or statistical table to find the row count, which is quite same as real row count.

Because the nature of MVCC, sometimes you can find the difference between actual record count and statistical table’s record count.

What is Multi Version Concurrency Control (MVCC)

You can easily find roughly row count using statistical tables within 1 second.

I tested and compared the two results in my local machine with the row count of 5000000000.

My COUNT (*) returns a result after 8 to 10 minutes and also taken 10% to 25% CPU and Memory.
After this, I found row count from the statistical table, and it didn’t take even one second.

But I found the little difference between both the count. The count of a statistical table is higher than the actual count. (12585-row count is greater) because of MVCC.

You should configure auto-vacuum and analyze on the table.

I executed vacuum and analyze on the table, and now my count is same.

I would suggest, please use the statistical table for the row counts.
I am providing two different scripts for finding the rough row count in the PostgreSQL.

SELECT reltuples::bigint AS EstimatedCount
FROM   pg_class
WHERE  oid = 'public.TableName'::regclass;

SELECT 
	schemaname
	,relname
	,n_live_tup AS EstimatedCount 
FROM pg_stat_user_tables 
ORDER BY n_live_tup DESC;

In this post, I am sharing a script to find the table and column, which are not associated with any comment or description of PostgreSQL.

Self-documentation is a most important thing for every developer and organization.
In our company, We are very strictly following this rule as a database development standard in which we have to write a comment or description for every table and column.

You can also manage this description using different UML tools.
But better to other tools, we should write in the database so whenever you create a database diagram, comment or description added automatically.

The Humans are doing a mistake, so sometimes I have to find such a list objects which didn’t associate with any comment or description.

I filtered below query by giving User_Name in WHERE clause, so if you want for all users, you should remove this filter.

Find Table without comment.

SELECT 
	pg_get_userbyid(pc.relowner)AS ObjectOwner
	,pc.relname AS TableName
	,pd.description AS Comment
FROM pg_class AS pc
LEFT OUTER JOIN pg_description AS pd 
	ON (pc.oid = pd.objoid)
WHERE pg_get_userbyid(pc.relowner) ='User_Name'
	AND pc.relkind = 'r'
	AND pd.description IS NULL;

Find Column without comment.

SELECT 
	pg_get_userbyid(pc.relowner) AS ObjectOwner
	,pc.relname AS TableName
	,pa.attname AS ColumnName
	,pd.description AS Comment
FROM pg_attribute AS pa
JOIN pg_class AS pc 
	ON (pa.attrelid = pc.oid)
LEFT OUTER JOIN pg_description AS pd 
	ON (pc.oid = pd.objoid AND pa.attnum = pd.objsubid)
WHERE pg_get_userbyid(pc.relowner) ='User_Name'
	AND pc.relkind = 'r'
	AND pd.description IS NULL
	AND pa.attnum > 0
ORDER BY pa.attname;