# Adding an Index to the `Build Side`

__*Diagram serves the next slide not this this slide.*__

![`smart`](TuningJoinByExplainAnalyze02_en_001_20230129.png)

------------------------------------------------------------------------------
In the slide, an index was added to the `BIRTH_DATE` column of the `EMPLOYEES` table, changing the `TableReader_25(Build)` operator to an `IndexLookUp_29(Build)` operator. As a result, the `Selection_24` operator was removed. This adjustment addressed the issue where the `actRows` value of the `HashJoin_20` operator was significantly lower than that of its second child operator, `TableReader_22(Probe)`, which had a much higher row count.

The observed discrepancy indicates that the number of rows from the `SALARIES` table involved in the join is relatively small. To optimize performance, it is advisable to switch from `HashJoin` to `IndexJoin` or `IndexHashJoin`. 

The `IndexJoin` or `IndexHashJoin` methods require the table with fewer rows to be the driving table, and an index should be created on the join column of the driven table. In this case, the `EMPLOYEES` table has only 93 rows involved in the join, whereas the `SALARIES` table has 2,044,047 rows. Therefore, the `EMPLOYEES` table is more suitable as the driving table. The next step is to create an index on the `EMP_NO` column of the `SALARIES` table.