While doing ad hoc queries I've seen several different problems that all seem to be variations on a theme.
The plan comes out looking like this:
Nested Loop (cost=826867.95..877038.04 rows=1 width=125)
Join Filter: (foo.bar = smallish_table.bar)
-> Something Complicated (cost=826867.95..876800.28 rows=1 width=81)
.....
-> Seq Scan on smallish_table (cost=0.00..142.89 rows=7389 width=44)
The estimate of rows=1 for Something Complicated is wrong and you really get 1000 or 100,000 rows. Meaning the seq scan on smallish_table gets iterated a lot, and the time really adds up.
It would be great if Something Complicated had the correct row estimate, but since I've seen this situation arise with a lot of different Something Complicated that don't have much to do with each other (although usually an antijoin of some kind is involved) , there is little reason to think we can squash every one of them.
Is there some principled way to go about teaching the planner that hashing smallish_table on the join filter key is a cheap insurance policy against underestimating the row count of the outer loop?
Cheers,
Jeff
