In the previous post, I have explained basic about the SQL Server Fillfactor.

SQL Server: Index Performance Tuning with the Fill Factor

In this post, I am going to share some scripts to configure Fill Factor for Index and SQL Server Instance.

Check the default Fillfactor value for SQL Server Instance:

SELECT *
FROM sys.configurations
WHERE name ='fill factor (%)'

Change the SQL Server default Fillfactor from (0 or 100) to 80:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'fill factor', 80;
GO
RECONFIGURE;
GO

Check the Fillfactor value for Indexes:

SELECT 
	OBJECT_NAME(OBJECT_ID) Name
	,type_desc
	,fill_factor
FROM sys.indexes

Create new Index with Fillfactor option:

CREATE TABLE tbl_TestFillFactor
(
	ID INTEGER PRIMARY KEY
	,Name VARCHAR(50)
)
GO
CREATE NONCLUSTERED INDEX idx_TestFillFactor 
ON tbl_TestFillFactor(Name) WITH (FillFactor = 80)
GO

Alter existing Index to change Fillfactor value:

ALTER INDEX idx_TestFillFactor ON tbl_TestFillFactor
REBUILD WITH (FILLFACTOR = 90)
GO

In this post, I am sharing a script to check a Fillfactor value, for tables or indexes of PostgreSQL Database Server.

I have already published importance of Fillfactor in PostgreSQL.

When we are working with the large database system, and we set Fillfactor value of multiple objects, sometimes it is required to check the value of current Fillfactor for those objects.

I prepared one script with “reloptions” column in which you can find “{fillfactor=value}” if it is assigned then only otherwise it is NULL.

SELECT 
	pc.relname AS ObjectName 
       ,pc.reloptions AS ObjectOptions
FROM pg_class AS pc
INNER JOIN pg_namespace AS pns 
	ON pns.oid = pc.relnamespace
WHERE pns.nspname = 'public'
	AND pc.relname = 'Table_Name';

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 to measure the size of a PostgreSQL Table Row.

I taken reference from this dba.statckexchange.

But again, I would like to share this information with some additional information.

Fillfactor storage parameter of PostgreSQL Table.

Before changing the default value of Fillfactor, we should measure the size of Table Row.

For knowing the row size is very important because if table row size is larger, we should not change the default value of Fillfactor.

When we are doing performance optimization, this is very important to find the size of the Data page and Table row, otherwise unnecessary we are dealing with high fragmentation and executing VACUUM FULL or VACUUM again and again.

If your total row size is under 8kb, you can take decision to alter table storage parameters.

Create sample table using JSON data type:

CREATE TABLE tbl_TestJSON
(
	ID INTEGER PRIMARY KEY
	,DepartName VARCHAR(250)
	,EmployeeDetails JSON
	,Address JSON
);

Insert few sample JSON formatted record:

INSERT INTO tbl_TestJSON
VALUES 
(
	1
	,'Sales'
	,'{"firstName": "Anvesh", "lastName": "Patel"}'
	,'
	{"address" : 
		{ 
			"India": "Hyderabad"
			,"USA": "Newyork"
		}
	}'
)
,(
	2
	,'Production'
	,'{"firstName": "Neevan", "lastName": "Patel"}'
	,'
	{"address" : 
		{ 
			"India": "Ahmedabad"
			,"USA": "Washington DC"
		}
	}'
)
,(
	3
	,'Animation'
	,'{"firstName": "Eric", "lastName": "Lorn"}'
	,'
	{"address" : 
		{ 
			"India": "Mumbai"
			,"USA": "Chicago"
		}
	}'
);

Script to measure the size of Table row and Data page:

WITH cteTableInfo AS 
(
	SELECT 
		COUNT(1) AS ct
		,SUM(length(t::text)) AS TextLength  
		,'public.tbl_testjson'::regclass AS TableName  
	FROM public.tbl_testjson AS t  
)
,cteRowSize AS 
(
   SELECT ARRAY [pg_relation_size(TableName)
               , pg_relation_size(TableName, 'vm')
               , pg_relation_size(TableName, 'fsm')
               , pg_table_size(TableName)
               , pg_indexes_size(TableName)
               , pg_total_relation_size(TableName)
               , TextLength
             ] AS val
        , ARRAY ['Total Relation Size'
               , 'Visibility Map'
               , 'Free Space Map'
               , 'Table Included Toast Size'
               , 'Indexes Size'
               , 'Total Toast and Indexes Size'
               , 'Live Row Byte Size'
             ] AS Name
   FROM cteTableInfo
)
SELECT 
	unnest(name) AS Description
	,unnest(val) AS Bytes
	,pg_size_pretty(unnest(val)) AS BytesPretty
	,unnest(val) / ct AS bytes_per_row
FROM cteTableInfo, cteRowSize

UNION ALL SELECT '------------------------------', NULL, NULL, NULL
UNION ALL SELECT 'TotalRows', ct, NULL, NULL FROM cteTableInfo
UNION ALL SELECT 'LiveTuples', pg_stat_get_live_tuples(TableName), NULL, NULL FROM cteTableInfo
UNION ALL SELECT 'DeadTuples', pg_stat_get_dead_tuples(TableName), NULL, NULL FROM cteTableInfo;

This is one of the most important articles for all PostgreSQL Database Professionals because it relates to PostgreSQL database optimization

First, You guys have to know what is MVCC and how it manages the different row versions.

What is Fillfactor and how it impacts the performance?

The Fillfactor is a table storage parameter and for the performance aspect this is the most important parameter.

The Fillfactor for a table is a percentage between 10 and 100. 100 is the default for a complete packing.

Because of this default 100 value, when one UPDATE is performed, the old tuple is marked as deleted and a new tuple is inserted into another page.
There is no extra space to write a new tuple on the same page because default 100 means write data in page till its full.

Now, next impact of this default 100 is, related indexes of newly updated records are modified because it has to point to the new page location.

If you notice here, for one UPDATE actually there are three operations, first mark deleted tuples, write new tuples in the new pages, and index modifications.

This is not just about the UPDATE but actually the performance of SELECT query also will degrade because of the internal fragmentation.

How can we improve the performance?6

The default Fillfactor is 100 and it is better, but not in all situations.
When your table has frequent updates, this is not a better solution because it requires more CPU and IO for different data page operations which actually degrade the performance.

The solution is to first measure the size of the tuple and if tuple size is not that much bigger, we can reduce the value of default Fillfactor.

How to measure the size of the tuple in PostgreSQL?

How to change the current value of Table Fillfactor in PostgreSQL?

When we reduce the default value of Fillfactor, each page has some free space and new tuple which is generated by UPDATE can be stored on the same page.

Now, index page does not require any modification because new tuple is on the same page.