Re: Why does not perform index combination

From: "Adnan DURSUN" <a_dursun(at)hotmail(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Why does not perform index combination
Date: 2006-02-16 22:14:56
Message-ID: BAY106-DAV1859B44CE7651F57F20E10FAFB0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>From: Tom Lane
>Date: 02/16/06 19:29:21
>To: Adnan DURSUN
>Cc: pgsql-performance(at)postgresql(dot)org
>Subject: Re: [PERFORM] Why does not perform index combination

>"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.

Yes, a narrower date range solves that.. Thanks for your suggestions...

>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.

Database was vacuumed and analyzed before got take the plan..

Regards
Adnan DURSUN

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Lewis 2006-02-16 22:17:36 Re: qsort again (was Re: [PERFORM] Strange Create Index
Previous Message Neil Conway 2006-02-16 19:14:03 Re: qsort again (was Re: [PERFORM] Strange Create Index