Thread-Index: AceY/yUneSPYgyRsTzqu29G9gqbWyg==
Message-ID: <464D21CD.5060907@enterprisedb.com>
Content-class: urn:content-classes:message
Importance: normal
Date: Fri, 18 May 2007 09:17:25 +0530
From: "Atul Deopujari" <atuld@enterprisedb.com>
User-Agent: Thunderbird 2.0a1 (X11/20060724)
MIME-Version: 1.0
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Atul Deopujari" <atul.deopujari@enterprisedb.com>,
	"Neil Conway" <neilc@samurai.com>, <pgsql-hackers@postgresql.org>
Subject: Re: Planning large IN lists
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>
In-Reply-To: <12592.1179432985@sss.pgh.pa.us>
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


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