In this post, I am sharing a script to generate ALTER statements to rename all PostgreSQL table names and column names in lower case.

Many times, I have found that PostgreSQL database developers are creating their object using pg admin GUI explorer. It by default adds a double quote to differentiate identifier.

For example, table name like “TableName” is a difference then “tablename”.

PostgreSQL: Why identifiers are Case-Sensitive

In one of our project, I found this kind of object names so prepared below script to ALTER object name into Lowercase which made all object name case insensitive.

Generate ALTER script to rename all tables into lower case letters:

SELECT 'alter table "'||c.relname||'" rename to '||lower(c.relname)||';'
FROM pg_catalog.pg_class c
     LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind ='r'
      AND n.nspname='public'
ORDER BY 1;

Generate ALTER script to rename all columns into lower case letters:

SELECT
        'alter table "'||c.relname||'" rename "'||a.attname||'" to '||lower(a.attname)||';'
FROM pg_class c
JOIN pg_attribute a ON a.attrelid = c.oid
JOIN pg_type t ON a.atttypid = t.oid
LEFT JOIN pg_catalog.pg_constraint r ON c.oid = r.conrelid
	AND r.conname = a.attname
WHERE c.relnamespace = (select oid from pg_namespace where nspname='schema_name')
	AND a.attnum > 0 AND c.relkind ='r'      
ORDER BY a.attnum

In MySQL 5.5 and higher version, Index performance has improved a lot.
MySQL InnoDB engine has basically two types of index, Primary clustered index and Secondary indexes.

When we are adding or dropping a clustered index, It is copying the data, and creating a new copy of the table.
Yes, this is the basic nature of any clustered index because It also contains the data value.

But, what about Secondary Index of MySQL InnoDB ?

When we are adding or dropping a secondary index, internally It scans the table, and sorts the rows using memory buffers in order by the values of the secondary index key columns.

Once a CREATE INDEX or ALTER TABLE statement starts to create InnoDB secondary index, we can only read the table, but cannot update the table.

Now Imagine, that we have a table with billions of data and now we require to add few more secondary indexes.
I have noticed that, most of the database developers create individual CREATE INDEX statement and execute each for creating require indexes.

We should not do this way because every CREATE INDEX statement require clustered index scan and other sorting related operation which actually degrade the performance of CREATE or DROP secondary index.

If we are adding or dropping multiple Indexes at a time, We can increase the performance of CREATE INDEX and DROP INDEX by executing using one single ALTER TABLE command.

If we are dealing with bulk-insert operation, we should create require indexes after data insertion which increase the performance of bulk-insertion.

For you guys, small demonstration to add or drop multiple indexes using one ALTER COMMAND.

Create a sample table:

CREATE TABLE tbl_Employees 
(
	EmpID INT PRIMARY KEY
	,EmpName VARCHAR(50)    
	,EmpSalary INT
	,EmpGrade CHAR(1)
);

Insert few sample records:

INSERT INTO tbl_Employees VALUES 
(1,'Anvesh',90000,'A'),(2,'Neevan',120000,'B')
,(3,'Roy',60000,'B'),(4,'Mahi',140000,'A')
,(5,'Martin',50000,'D'),(6,'Eric',80000,'C');

One ALTER command to add multiple Indexes on Table:

ALTER TABLE tbl_Employees 
ADD INDEX (EmpName), ADD INDEX (EmpGrade);

One ALTER command to drop multiple Indexes on Table:

ALTER TABLE tbl_Employees 
DROP INDEX EmpName, DROP INDEX EmpGrade;

This is one of the important post related to change or set the Fillfactor value for the existing table of the PostgreSQL.

One of our tables is very busy with a large number of updates and access by multiple clients.

I also estimated the row size of that table which is not that much bigger, so I decided to change the Fillfactor of that table.

I have recently published an article about the importance of Fillfactor in PostgreSQL.

ALTER TABLE table_name SET ( fillfactor = 50);
VACUUM FULL table_name;

Please Note:

After changing the value of Fillfactor, you should execute VACUUM FULL on that particular table.
After changing the value of Fillfactor, it works only for new tuples.

In this post, I am sharing a script which we can use for changing ownership of all objects in PostgreSQL.

Why ownership of object needs to change?

I have created one application user for our production PostgreSQL database.

But system admin and deployment manager made one mistake and executed objects with some another database user.

After deployment, we came to know that objects were not deployed under proper ownership.

Now we have 2500 tables, 450 views and 230 stored functions are required to change their ownership.

Now, I need to solve this by using only one script because of manual changing ownership of this many objects will take too much time.

Below is my demonstration:

Let’s First, create one function with $parameter value so that you can use this function as a template.

CREATE OR REPLACE FUNCTION ChangeObjectsOwnerShip(text) 
returns text language plpgsql volatile
  AS $f$
    BEGIN
      EXECUTE $1;
      RETURN $1;
    END;
$f$;

Now generate two select statements to get the alter script.

Below select statement is for Tables, Sequences and Views.

SELECT ChangeObjectsOwnerShip
(
 'ALTER TABLE ' || quote_ident(s.nspname) || '.' ||quote_ident(s.relname) || ' owner TO app_user'
)
FROM 
(
 SELECT 
  nspname
  ,relname
 FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid) 
 WHERE nspname NOT LIKE E'pg\\_%' 
  AND nspname <> 'information_schema' 
  AND relkind IN ('r','S','v') ORDER BY relkind = 'S'
)s;

Below select statement is for all functions.

SELECT ChangeObjectsOwnerShip
(
 'ALTER FUNCTION ' || quote_ident(s.nspname) || '.' ||quote_ident(s.function_name) || '('||s.parms||') owner TO app_user'
)
FROM 
(
 SELECT 
  nspname
  ,proname AS function_name
  , pg_catalog.oidvectortypes(proargtypes) AS parms
 FROM pg_catalog.pg_proc AS c
 JOIN pg_namespace n
  ON (c.pronamespace = n.oid)
 WHERE nspname != 'information_schema'
  AND nspname NOT LIKE E'pg\\_%'
 ORDER BY proname
)s;

In above code, preparing one alter statement to change ownership for all objects from assign user to mentioned ” app_user “. You can change ” app_user ” by your require user name.

After executing above select statements, you can find all alter scripts in a result.

Copy this result and execute above alter scripts using super user.

All ownership will be changed after executing this alter the script.