"Adnan DURSUN" <a_dursun@xxxxxxxxxxx> writes: > I have query for a report. Explain analyze result is below. The = > execution plan tells that it would use "t_koltuk_islem_pkey" index on = > table "t_koltuk_islem" to scan. However, there is another index on table = > "t_koltuk_islem" on column "islem_tarihi" that can be combined on plan. = > Why doesn't optimizer choice that ? It prefer to perform a filter on = > column "islem_tarihi" ... Why ? Probably thinks that the extra index doesn't add enough selectivity to be worth scanning. It's probably right, too --- maybe with a narrower date range the answer would be different. I think the main problem in this plan is the poor estimation of the size of the d1/s join. Are your stats up to date on those tables? Maybe boosting the statistics target for one or both would help. regards, tom lane
