However, if the primary key is entirely within those six columns, there
will have to be an index on it in both tables to enforce the primary key
constraint. In that case, an inner join could be performed with an index
lookup or an index scan plus hash join, for a query that didn't use any
other columns. Whether that translates into a significant I/O reduction
depends on how wide and how frequently non-NULL those other columns are.
... if someone is feeling pedagogical (and the answer isn't that
complicated), could they explain why a simple index on the desired
columns wouldn't be the best solution?
Cheers
Antoine
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
