From: Atul Deopujari <atuld@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Atul Deopujari <atul.deopujari@enterprisedb.com>
Cc: Neil Conway <neilc@samurai.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Planning large IN lists
Date: Fri, 18 May 2007 09:17:25 +0530
Message-ID: <464D21CD.5060907@enterprisedb.com> (raw)
In-Reply-To: <12592.1179432985@sss.pgh.pa.us>
References: <1178821226.6034.63.camel@goldbach>
<19001.1178823208@sss.pgh.pa.us>
<464C1CA0.1060705@enterprisedb.com>
<23045.1179408878@sss.pgh.pa.us>
<464CA680.7040904@enterprisedb.com>
<12592.1179432985@sss.pgh.pa.us>
Tom Lane wrote:
> "Atul Deopujari" <atuld@enterprisedb.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: atuld@enterprisedb.com, tgl@sss.pgh.pa.us, atul.deopujari@enterprisedb.com, neilc@samurai.com
Subject: Re: Planning large IN lists
In-Reply-To: <464D21CD.5060907@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox