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.

Table Scan:

It scans every row for finding a particular node or data. If the planner fails to use a proper index, it has to do full Table Scanning.
If table has a less number of records, Table Scan is an excellent choice for query optimizer.

For example, If Table has around 1000 records, Table Scan is faster because unnecessary Index Scanning operation is not required.
But, If the Table has a large number of records, Table Scan requires high CPU and other resources for scanning the whole table.

Index Scan:

It is scanning of each row, whenever you are retrieving more than 50% or 70% of the table data, internally planner performing full Index Scan.

Generally, Index pages and Data pages are stored separately.
Index scanning is also dependent on the ordering of the Index data because If matched key found from the top pages, Index Scan is not required.

The Row Lookups also involved in Index Scanning because matched Index key has to fetch data from the data page, so Index Scanning is very costly for the big table.

Index Seek:

Index Seek is opposite the Table Scan and Index Scan.
It touches the only qualified row index rather than scanning whole Index Pages, and after that, it fetches only qualified data page.

When we are fetching less number of records with the specific filter, the planner has to choose Index Seek to fetch and scan only qualified data.

Index Seek operation is much faster than Index Scan, and also it does not require more CPU and I/O resources.