SQL Server 2016 introduced Database Scoped Configuration Options that can set at the database level, which was previously available at the instance level only.

In SSMS, you can right click on database -> go to -> option -> find Database Scoped Configuration section.
It introduced main four parameters, which we can set at the database level.

Legacy Cardinality Estimation: It enables you to configure the query optimizer cardinality estimation model.

MAXDOP: Maximum degree of parallelism for an individual database.

Parameter Sniffing: Previously, we can disable this feature using trace flag 4136, but now you can ON/OFF Parameter Sniffing at the database level.

Query Optimizer Fixes: You can enable or disable query optimization hotfixes.

Clear Database Plan: It allows clearing procedure cache at the database level without impacting other databases.

SQL Server 2016 also introduced one DMV to check the current value of Database Scoped Configurations.

SELECT *FROM sys.database_scoped_configurations

Database user requires Scoped Configuration permission to execute ALTER SCOPED CONFIGURATION.

GRANT ALTER ANY DATABASE SCOPED CONFIGURATION to UserName;

Related T-SQL Scripts:

Clear atabase Plan Cache:

ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

Enable Legacy Cardinality Estimation:

ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = ON;

Set MAXDOP Value:

ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 3;

Disable Parameter Sniffing:

ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SNIFFING = OFF;

Enable Query Optimizer Fixes:

ALTER DATABASE SCOPED CONFIGURATION SET QUERY_OPTIMIZER_HOTFIXES = ON;

Like any other RDBMS, PostgreSQL generates a Query Execution Plan for each query that it receives.

It is also used Genetic Query Optimizer (GEQO) that does query planning for heuristic search and It reduce query planning time for large and complex queries.

An Optimizer always tries to choose a good Query Execution Plan.

The structure of Query Execution Plan is like a Tree and It contains different information like: type of scan details, join details, sorting details, aggregation details, Estimated rows details, Estimated start-up cost, Estimated total cost and others.

To know about the Query Execution Plan, is very important for all Database Professionals because It helps us to improve the Query Performance.

With the help of Query Execution Plan, We can make our decisions on Index tuning, Join tuning and other.

In PostgreSQL, we have EXPLAIN and EXPLAIN ANALYZE command to know about the Query Execution Plan.

Here, I have used one table tbl_itemtransactions which you can create using below post.

Example of EXPLAIN: It generates the Estimated Query Execution Plan with out executing an actual SQL Query.

EXPLAIN SELECT COUNT(1) FROM tbl_itemtransactions;

/*
Result: 
"Aggregate  (cost=2555525.00..2555525.01 rows=1 width=0)"
"  ->  Seq Scan on tbl_itemtransactions  
(cost=0.00..2216945.00 rows=135432000 width=0)"
*/

Example of EXPLAIN ANALYZE: It first executes the SQL Query and than It generates the actual Query Execution Plan.

EXPLAIN ANALYZE SELECT COUNT(1) FROM tbl_itemtransactions;

/*
Result: 
"Aggregate  (cost=2555525.00..2555525.01 rows=1 width=0) 
(actual time=52660.132..52660.133 rows=1 loops=1)"
"  ->  Seq Scan on tbl_itemtransactions  
(cost=0.00..2216945.00 rows=135432000 width=0) 
(actual time=0.027..46193.484 rows=135432001 loops=1)"
"Planning time: 0.204 ms"
"Execution time: 52660.237 ms"
*/