The newly introduced BRIN (Block Range Index) Index is one my favourite index type of RDBMS system like PostgreSQL.

The BRIN index is stored the only summary of data pages instead of storing actual key data. It is 10 times faster than the normal BTREE Index.

I have already published articles on What is BRIN and How we can implement BRIN in PostgreSQL 9.5.?

Database Theory: What is BRIN (Block Range Index), How is faster than BTREE Index

PostgreSQL 9.5: Introduced BRIN – Block Range Index with Performance Report

In this post, I am sharing maintenance part of BRIN Index.

Database Administrators are doing maintenance of Indexes on a regular basis like Rebuild Index, Reorganize Index, Update Statistics of Indexes.

But these types of maintenance will not work for BRIN Indexes because BRIN Indexes are not storing any actual data and it stores only a summary of the data page.

PostgreSQL 9.5 also introduced brin_summarize_new_values() BRIN Index maintenance function.
This function is used to find a new range of pages which are not yet summarized by BRIN Index.

It performs the table scanning and creates a new summary index tuple for newly added data pages and adds into BRIN Index. It also returns a count of total newly added pages.

The syntax is:

SELECT brin_summarize_new_values('BRIN_Index_Name');

In this post, I am sharing a script for checking the newly allocated pages to the table of SQL Server.

The use of this script is in very rare condition. If you are doing deep work like monitoring allocation and space management, you will need this kind of script.

For example, If you are doing bulk load, data page allocation should be in sequence for better performance. You can use this script for comparing page allocation before and after of Bulk load activity.

Below is a script:

SELECT 
	OBJECT_NAME(p.object_id) AS object_name
	,i.name AS index_name
	,ps.in_row_used_page_count
FROM sys.dm_db_partition_stats ps
JOIN sys.partitions p
       ON ps.partition_id = p.partition_id
JOIN sys.indexes i
       ON p.index_id = i.index_id
       AND p.object_id = i.object_id

I shared a couple of articles on SQL Server database locking and how to detect a deadlock. Please access few of them.

Different ways to detect a deadlock
What happens after the Deadlock?

I recently found an undocumented function %%lockres%% which we can use to locate the page information of records especially for those records which hold a Lock.

It returns a hash value same as like column “resource_description” of table sys.dm_tran_locks, but the good thing is you can use it in your SELECT statement and can correlate the column resource_description of table sys.dm_tran_locks.

By this way, you can get the exact record, and it’s page info which currently held by a Lock.

Let me demonstrate this,
Prerequisites:
Use below article and generate a sample deadlock situation in your database server.

SQL Server: T-SQL script to generate a DeadLock in a Database

Check the result of below query and note down the result of column “resource_description”:

select *from sys.dm_tran_locks

Use %%lockres%% and SELECT both the tables:
You can easily correlate the result of sys.dm_tran_locks column resource_description and the result of %%lockres%%. You can find an exact record which held by a Lock.

SELECT %%lockres%% AS RecordPageInfo,* 
FROM tbl_SampleTable_A

SELECT %%lockres%% AS RecordPageInfo,* 
FROM tbl_SampleTable_B

After this exercise, Please COMMIT all your open transactions.

PostgreSQL stores data into logical equivalent pages.

The size of each data page is 8KB.
The structure used to store the table is a heap file which also stores header information like: checksum, start of free space, end of free space.

It contains a pair of offset & length, which actually points to the actual items.

Postgres data called immutable row data. These immutable rows are called “tuples” in PostgreSQL.
Tuples are uniquely identified by ctid. A ctid conceptually represents the physical disk location for a tuple.

Because of MVCC architecture, multiple ctid can describe a single row which sometime degrade the write performance of PostgreSQL.

What is Multi Version Concurrency Control (MVCC)

For example,
When we are updating any data, internally MVCC inserts new version of record and marks old record as dead row.

This operation requires to create new ctid for new rows, new link for index, remove old link of record.
Yes, this is good to avoid locking issue, but write performance is not that much good.

A CTIDs are transparent to users, and any user can check table CTID by adding one additional ctid column in any of the table.
PostgreSQL internally creates CTID column for each and every table.

For example,

SELECT CTID,* FROM tbl_Employees;

Execute VACUUM or AUTO-VACUUM is required to increase the overall performance of PostgreSQL which removes the dead rows or old version rows, generated by MVCC architecture.

PostgreSQL: Short note on VACUUM, VACUUM FULL and ANALYZE