Michael Fuhr <mike@xxxxxxxx> writes: > I created a test case that has close to the same estimated and > actual row counts and has the same plan if I disable enable_nestloop: There's something weird about this --- why does the second plan seqscan b_saskaita, instead of using the bitmap scan that it had previously estimated to be cheaper? What PG version are you testing, and can you provide the full test case? (As for the original question, the hash plan seems to me to be perfectly reasonable for the estimated row counts --- fetching one row out of fifty using an indexscan is going to be expensive. So I think the OP's problem is purely a statistical one, or maybe he's in a situation where he should reduce random_page_cost.) regards, tom lane
