For all the RDBMS, Database Statistics are playing the main role to generate an accurate Query Execution Plan.
A Database Administrator is also very much responsible to make sure that Database Statistics is updated.

MySQL query optimizer is also preparing Query Execution Plan with the help of Statistics Information.
The auto-update Statistics configuration is also very important to keep Statistics updated.

How to enable auto-update Statistics for InnoDB engine?

We can configure innodb_stats_on_metadata variable to enable auto-update Statistics.

When this variable is enabled InnoDB updates statistics when metadata statements such as SHOW TABLE STATUS or SHOW INDEX are run, or when accessing the INFORMATION_SCHEMA.TABLES or INFORMATION_SCHEMA.STATISTICS tables.

Check innodb_stats_on_metadata is ON or OFF:

SHOW VARIABLES LIKE 'innodb_stats_on_metadata';

If innodb_stats_on_metadata is OFF, make it ON:

SET GLOBAL innodb_stats_on_metadata=ON;

When you perform command like SHOW INDEX, Statisitcs will be update.
Accuracy of statistics is depends on MySQL Server Load.

SHOW INDEXES FROM SchemaName.TableName;

You can use below query to check the Index Statistics:

SELECT 
    Table_Schema
    ,Table_Name
    ,Non_Unique
    ,Index_Schema
    ,Seq_In_Index
    ,Column_Name
    ,Collation
    ,Cardinality
    ,Index_Type
FROM information_schema.statistics 
WHERE TABLE_SCHEMA='SchemaName';

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.

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