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: | Raw Message | Whole Thread | 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 |