From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Adnan DURSUN" <a_dursun(at)hotmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Why does not perform index combination |
Date: | 2006-02-16 17:27:36 |
Message-ID: | 29367.1140110856@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Adnan DURSUN" <a_dursun(at)hotmail(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2006-02-16 18:39:45 | Re: qsort again (was Re: [PERFORM] Strange Create Index |
Previous Message | Scott Lamb | 2006-02-16 17:19:24 | Re: qsort again (was Re: [PERFORM] Strange Create |