Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45E36E6B.6020904@sbcglobal.net>
Date: Mon, 26 Feb 2007 15:34:03 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Commented: (DERBY-47) Some possible improvements to IN
 optimization
References: <16929986.1172252646922.JavaMail.jira@brutus>
 <45E3091B.40208@gmail.com>
In-Reply-To: <45E3091B.40208@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

please go ahead with your patch - I think the changes are good 
incremental steps.  The approach with using the flag and code
reuse seems reasonable.

I am interested in the costing but I think that is separate from
the work you are doing.  What you have implemented seems in line
with the current behavior.  My itch here was I have been trying
to understand the problems caused by not having available
selectivity stats, and if store could provide some better estimates
if the complete stat is not available.  This is no way should
hold up your IN work.

Army wrote:
> A B (JIRA) wrote:
> 
>>
>> A B commented on DERBY-47:
>> --------------------------
>>
>> Thank you very much for your excellent questions, Mike.  My attempted 
>> answers are below...
> 
> 
> Hi Mike,
> 
> Just wondering if you had any additional questions/inquiries regarding 
> my previous responses to your comments?  If not, I'd like to commit 
> d47_relOpPredCheck_v1.patch to trunk and proceed from there...
> 
> Thanks again for the feedback!
> Army
> 
> 
>