Re: why sequential scan is used on indexed column ???

Michael Fuhr <mike(at)fuhr(dot)org> 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