Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (nike.apache.org: domain of jamisonlists@gmail.com
 designates 209.85.217.16 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=qjHhUnEd9ITRqcSVHvoBX1hd8GpdrzQU3D7qTpmu+xIVTgpMR0gNrtyhyQQS2Kwqin
         QlEF5ThspcvDV//6BvobpFuEKd/JR9xSIzaHQhYPM8Dru+4xSlPAp5vg99bCFITqGBW7
         K+LHVRR+CW2G6NgEf0O9/s4mTh4lArBQb2Z2E=
MIME-Version: 1.0
In-Reply-To: <21574300.post@talk.nabble.com>
References: <21568317.post@talk.nabble.com>
	 <a10a823c0901201013i5ed2c09etda1f722b77b37f75@mail.gmail.com>
	 <21568697.post@talk.nabble.com> <21568927.post@talk.nabble.com>
	 <a10a823c0901201122t6b263d8cp21252703110131e8@mail.gmail.com>
	 <21574300.post@talk.nabble.com>
Date: Sat, 24 Jan 2009 12:26:55 -0600
Message-ID: <71d231c70901241026s3814e6cag401f30a4a3ae8c1e@mail.gmail.com>
Subject: Re: Excessive memory usage (feature or bug?)
From: j-lists <jamisonlists@gmail.com>
To: user-java@ibatis.apache.org
Content-Type: multipart/alternative; boundary=000e0cd4856470087e04613ea6d9

--000e0cd4856470087e04613ea6d9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This conversation inspired a rather off-topic question from me, in mysql are
you forced to hardcode the limit/offset in to the SQL like this?
limit $skip$, $max$

In Postgres they can bind as parameters:
limit #limit# offset #offset#

I'm not really a mysql user so I am curious...

-J

On Tue, Jan 20, 2009 at 5:46 PM, Jeff P <killingdjef@hotmail.com> wrote:

>
> Thank you alot, Larry!!!
>
> It really scared the hell out of me when I checked the profiler and saw
> that
> 1 query used so much memory.
> I can confirm that using your technique reduced ram usage to 5mb (which is
> practically nothing!)
>
> Thanks again!
>
>
> Larry Meadors wrote:
> >
> > Ha, yeah, it's the driver for sure. You'll get the same results if you
> > prepare and execute the statement yourself instead of using ibatis.
> >
> > I remember when looked at the source for the pgsql driver some time
> > ago - it does a similar thing - it fetched the results of the query
> > into a big freaking byte[][] structure (assuming that you'll need it
> > all) then walked through it as I called rs.next().
> >
> > Even a RowHandler won't help because it's happening before ibatis gets
> > to touch the data - it happens when you execute the statement.
> >
> > Use the limit trick in your select statement. It's the only way to
> > prevent this problem if the driver does this.
> >
> > Larry
> >
> >
> > On Tue, Jan 20, 2009 at 11:34 AM, Jeff P <killingdjef@hotmail.com>
> wrote:
> >>
> >> For what its worth... my profiler says the 3 biggest memory hogs are:
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Excessive-memory-usage-%28feature-or-bug-%29-tp21568317p21574300.html
> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>
>

--000e0cd4856470087e04613ea6d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This conversation inspired a rather off-topic question from me, in mysql are you forced to hardcode the limit/offset in to the SQL like this?<br>limit $skip$, $max$<br><br>In Postgres they can bind as parameters:<br>limit #limit# offset #offset#<br>
<br>I&#39;m not really a mysql user so I am curious...<br><br>-J<br><br><div class="gmail_quote">On Tue, Jan 20, 2009 at 5:46 PM, Jeff P <span dir="ltr">&lt;<a href="mailto:killingdjef@hotmail.com">killingdjef@hotmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Thank you alot, Larry!!!<br>
<br>
It really scared the hell out of me when I checked the profiler and saw that<br>
1 query used so much memory.<br>
I can confirm that using your technique reduced ram usage to 5mb (which is<br>
practically nothing!)<br>
<br>
Thanks again!<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
Larry Meadors wrote:<br>
&gt;<br>
&gt; Ha, yeah, it&#39;s the driver for sure. You&#39;ll get the same results if you<br>
&gt; prepare and execute the statement yourself instead of using ibatis.<br>
&gt;<br>
&gt; I remember when looked at the source for the pgsql driver some time<br>
&gt; ago - it does a similar thing - it fetched the results of the query<br>
&gt; into a big freaking byte[][] structure (assuming that you&#39;ll need it<br>
&gt; all) then walked through it as I called rs.next().<br>
&gt;<br>
&gt; Even a RowHandler won&#39;t help because it&#39;s happening before ibatis gets<br>
&gt; to touch the data - it happens when you execute the statement.<br>
&gt;<br>
&gt; Use the limit trick in your select statement. It&#39;s the only way to<br>
&gt; prevent this problem if the driver does this.<br>
&gt;<br>
&gt; Larry<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Jan 20, 2009 at 11:34 AM, Jeff P &lt;<a href="mailto:killingdjef@hotmail.com">killingdjef@hotmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; For what its worth... my profiler says the 3 biggest memory hogs are:<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div></div><font color="#888888">--<br>
View this message in context: <a href="http://www.nabble.com/Excessive-memory-usage-%28feature-or-bug-%29-tp21568317p21574300.html" target="_blank">http://www.nabble.com/Excessive-memory-usage-%28feature-or-bug-%29-tp21568317p21574300.html</a><br>

</font><div><div></div><div class="Wj3C7c">Sent from the iBATIS - User - Java mailing list archive at Nabble.com.<br>
<br>
</div></div></blockquote></div><br>

--000e0cd4856470087e04613ea6d9--