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?



Reply via email to