Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4DF254B0.9060109@oracle.com>
Date: Fri, 10 Jun 2011 10:30:24 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Modifying "sql join" optimization algorithm in Derby
References: <BANLkTim6iALCG6vmt6ws0ZRSm7USa8Lo-w@mail.gmail.com>
 <4DF2250B.1070608@oracle.com>
 <BANLkTimSybV3czBFWr2mBFOmN=0D46gYVw@mail.gmail.com>
In-Reply-To: <BANLkTimSybV3czBFWr2mBFOmN=0D46gYVw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 6/10/11 10:17 AM, Piumi Nanayakkara wrote:
> Hi,
>
> Thank you very much for your responses.
>
> Our tentative plan is to change currently available optimization 
> techniques in relation to seek time/rotational latency which comes 
> with the normal magnetic disk,but can be avoided in solid state memory 
> device. Initially we are focusing on the optimization of Join 
> operation in Apache Derby. We thought of first comparing the 
> performance in two modes of devices with existing algorithms ( i.e. 
> Nested Loop Join and Hash Join) & existing join order and then to 
> modify them to utilize the benefits of solid state devices.
>
> we highly appreciate any feedback on this or any suggestions of an 
> alternative approach that can be taken.
This sounds like a promising piece of research. It will be interesting 
to see if you can map the differences between solid-state and 
conventional disks onto the Cost Model variables in StoreCostController. 
Keep us posted as your research proceeds. Based on your findings, we may 
need to expand the existing Cost Model.

Thanks,
-Rick
>
>
> Best Regards,
> Piumi Nanayakkara
>
>
> On Fri, Jun 10, 2011 at 7:37 PM, Rick Hillegas 
> <rick.hillegas@oracle.com <mailto:rick.hillegas@oracle.com>> wrote:
>
>     On 6/10/11 1:07 AM, Piumi Nanayakkara wrote:
>
>         Hi all,
>
>         For a research purpose I'm considering $subject when database
>         is stored in a solid state device.Can some one please clarify
>         me the packages/classes that i should study/modify for this
>         purpose.
>         Thank You!
>
>
>         Best Regards,
>         Piumi Nanayakkara
>
>     Hi Piumi,
>
>     Probably what is most relevant is the Cost Model for these
>     devices. Derby ships with a hard-coded Cost Model for heap and
>     index files. That Cost Model was tuned many years ago and probably
>     doesn't capture the actual performance of modern disks. I was not
>     part of the effort to tune that Cost Model so I can't give you a
>     lot of detail here.
>
>     If you want to tweak the Cost Model to better reflect the
>     performance of solid state disks, I recommend that you study the
>     org.apache.derby.iapi.store.access.StoreCostController interface
>     and its implementations. Unfortunately, I am not aware of any
>     tools which will help you create an implementation which is tuned
>     to the behavior of a particular disk. You may develop such a tool
>     as you pursue your research. If so, I encourage you to donate that
>     tool back to the community. I'm sure it will be useful to other
>     researchers and developers.
>
>     Perhaps you will get more detailed advice from someone who was
>     closer to the original effort which tuned the current Cost Model.
>
>     Sounds like an interesting project. Good luck!
>
>     Cheers,
>     -Rick
>
>
>