As per the Microsoft, Use the cost threshold for parallelism option to specify the threshold at which Microsoft SQL Server creates and runs parallel plans for queries.

The Cost Threshold for Parallelism parameter is very important for Query Optimizer to prepare the query execution plan.

I wrote a title like Not Good – Because the default value of Cost Threshold for Parallelism is 5 which is very less now a day.

The value you define here which is for query optimizer where it finds a cheaper parallel execution plan, and if it fails to find parallel execution plan in given cost, it chooses the serial execution plan which degrades the query performance.

Now a day, we are dealing with millions/billions of data, so parallel query execution plan is good for big/complex queries so the default value 5 which is a tiny number.

The parallel execution plans will give you more suggestion on missing indexes which we can take for further query optimization.

I would suggest to change the value of Cost Threshold for Parallelism from 5 to 50 or even more.

How to change?

Using Script:

sp_configure 'show advanced options', 1;
GO
reconfigure;
GO
sp_configure 'cost threshold for parallelism', 50;
GO
reconfigure;
GO

Using SSMS:

Since SQL Server 2005, we have a concept of Forced Parameterization of SQL Query.

It looks like a very old concept, but the use of Forced Parameterization improves the performance of Query Optimizer which responsible for the best execution plan.

SQL Server provides two types of query parameterization, one is Simple Parameterization and second is Forced Parameterization.

Why it is important and How it works?

When you are executing any query, SQL Server Query Optimizer analyzes your query and prepares the best execution plan for it.

If you are executing the same query again, previously generated execution plan may use for the same query. We can also say that It caches your query execution plan.

It is doing this using a Simple Parameterization which is default in SQL Server.

Let me add one more thing,
Your frequent SQL Query uses the cache query plan, but what If you change the value in WHERE clause.

If you are changing just column filter value in WHERE clause, It uses the cache query plan and If you are modifying your parameter list, It requires to generate a new query plan.

This is about the Simple Parameterization.

You can see in the below image:

I have executed two different queries with passing different values for TrackingEventID.

But You can see TrackingEventID = @1 in query execution plan, means It uses same query plan for both the query which increase your query performance.

Now check below image:

I have used ISNULL() in query and It skipped to put parameter in the query of execution plan.
You can see static date value instead of parameter values.

If you are executing this kind of queries frequently, It prepares and generates an execution plan every time which decreases the query performance.

Now, enable the Force Parameterization and check the same query.

You can check below image where you can see parameter values instead of static date value.

Once you enable Force Parameterization, It forcefully adds the parameter in the query of execution plan.

Which improves the query performance by reducing the cost of preparing and compiling an execution plan again and again.

But we should also take care about this because It might generate SQL Parameter Sniffing Issue so we should keep database statistics up to date.

Script to change the database in Forced Parameterization:

ALTER DATABASE Database_Name
SET PARAMETERIZATION FORCED
GO

Script to change the database in Simple Parameterization:

ALTER DATABASE Database_Name
SET PARAMETERIZATION Simple
GO

Other related articles:

SQL Server: The Importance of Statistics and Why It is important

SQL Server Parameter Sniffing

Every day If you are doing performance optimization related stuff, sometime you also confuse on the decision of the Query Planner because It might be choose a wrong plan.

The SQL Server and MySQL provide features like: Index force or Index hint for SQL query, but PostgreSQL does not provide such feature because Once you set Index hint on the query, in future data is increasing and your Index hint might be not working accordingly.

Database Theory: Table Scan vs Index Scan vs Index Seek

In the PostgreSQL, Query Planner takes the decision base on the updated statistics and choose the Table Scan or Index Scan.

For smaller table, sequential scan is always faster compare to Index scanning. But sometimes what I have found is: due to invalid parameter PostgreSQL skips the indexes and start the table scanning which leads to poor performance.

In this situation, we should disable the Sequential Scan option so that Query Planner force to use available Indexes and execute the Query.

In PostgreSQL, We cannot enable / disable Index Scan or Table Scan at individual query level.

PostgreSQL provides two main parameters for Index Scan or Table Scan:
By default, this both parameters are ON, but as per the your requirement you can change the value.
You can find these parameters in postgresql.conf file.

enable_seqscan
enable_indexscan

You should never make the force on Query Planner because Forcing is a very bad idea. It might be useful to check if it will be faster, but production code should never use such tricks.

Before a few days ago, When I was performing query optimization at that time I have seen one warning in the result of SQL Server Query Execution Plan like: “Operator used tempdb to spill data during execution with spill level 2”.
I performed RND on this and came to know very interesting reason this warning.

If you don’t know, please note that Database Statistics are playing main to prepare and generate the Query Execution Plan.

SQL Server Statistics contain different types of meta data information like total number records, indexes, access path and others.

This warning occurred because my database Statistics are not updated.
For example, my table has total 50000 records and Statistics contains only 5000 records information so the planner prepares the query execution plan according to 5000 records only.

While executing the query, If it finds more than 5000 records, It transfers other additional records first into TempDB and continue further process using TempDB. Because It calculated processing capacity only for 5000 records.

This process degrades the overall query performance and that’s why you can see a warning like: “Operator used tempdb to spill data during execution with spill level 2”.

The solution is:

Find Statistics data for tables and indexes and If Statistics data are not updated, update your Statistics data, so that Query Optimizer can prepare the best Query Execution Plan.

Check the Statistics for particular index:
If you find difference between Rows and Rows Sampled, Statistics is not updated.

DBCC SHOW_STATISTICS ("TableName", IndexName);

Update all Statistics for Database:

EXEC sp_updatestats;

Update Statistics for Table:

UPDATE STATISTICS TABLE_NAME;

Update Statistics for Index:

UPDATE STATISTICS TABLE_NAME INDEX_NAME;

In this post, I am sharing two important parameters which might be useful to improve query execution process in MySQL Server.

The Query Optimizer is playing the main role in the Query Execution Process. It is responsible to choose best Query Execution Plan among the list of Plans.
In MySQL, we can control the task of Query Optimizer by setting few parameters.

Why because?

If you have one big SQL Query (included around 40 tables), Planner generates all possible plans mostly It generates 40+ query execution plan so now Query Optimizer will take more time to SELECT best plan.

We should tune this situation by knowing about optimizer_prune_level and optimizer_search_depth parameters.

optimizer_prune_level: Default is ON, It tells Query Optimizer to skip certain plans based on estimated number of rows.

If we have total 40 tables, Planner generates all possible 40+ plans including individual table plan which might not be needed for Query Optimizer.

If you believe that the optimizer missed a better query plan, this option can be switched off (optimizer_prune_level=0) with the risk that query compilation may take much longer.
This variable we can set both GLOBAL and Session level.

SHOW VARIABLES LIKE 'optimizer_prune_level';

SET GLOBAL optimizer_prune_level=0; -- For global change 
SET optimizer_prune_level=0; -- For session specific change

optimizer_search_depth: Default value is 62, the Planner is generating multiple plans, but sometimes It also generates an incomplete plan.

When Query Optimizer starts to scan the plan, we can set optimizer_search_depth value to tell how far each incomplete plan the optimizer should look to evaluate.

If we set a higher value (Max 63), Query Optimizer try to evaluate all incomplete plans which will take more time to execute. If we set lower value, Query Optimizer can skip few incomplete generated plans.

This variable we can set both GLOBAL and Session level.

SHOW VARIABLES LIKE 'optimizer_search_depth';

SET GLOBAL optimizer_search_depth=40; -- For global change 
SET optimizer_search_depth=40; -- For session specific change

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"
*/