| From: | "Atul Deopujari" <atuld(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Atul Deopujari" <atul(dot)deopujari(at)enterprisedb(dot)com>, "Neil Conway" <neilc(at)samurai(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Planning large IN lists |
| Date: | 2007-05-18 03:47:25 |
| Message-ID: | 464D21CD.5060907@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> "Atul Deopujari" <atuld(at)enterprisedb(dot)com> writes:
>> Yes, letting the planner make its own decision would seem best (in
>> accordance with what we do for different join paths). But for large IN
>> lists, a substantial part of the planner is spent in estimating the
>> selectivity of the ScalarArrayExpr by calling scalararraysel. If we are
>> not eliminating this step in processing the IN list then we are not
>> doing any optimization. Asking the planner to do scalararraysel and also
>> compute cost of any other way and choose between the two is asking
>> planner to do more work.
>
> So? Better planning usually involves more work. In any case the above
> argument seems irrelevant, because making scalararraysel more
> approximate and less expensive for long lists could be done
> independently of anything else.
>
Got you and agree with you.
--
Atul
EnterpriseDB
www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2007-05-18 04:53:52 | Re: Maintaining cluster order on insert |
| Previous Message | Andrew Dunstan | 2007-05-18 03:42:45 | Re: UTF8MatchText |