Return-Path: 
 <cocoon-dev-return-37675-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 41286 invoked by uid 500); 4 Mar 2003 16:27:53 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 41214 invoked from network); 4 Mar 2003 16:27:52 -0000
Received: from mailserver1.hrz.tu-darmstadt.de (130.83.126.41)
  by daedalus.apache.org with SMTP; 4 Mar 2003 16:27:52 -0000
Received: from paris (paris.dvs1.informatik.tu-darmstadt.de [130.83.27.43])
	by mailserver1.hrz.tu-darmstadt.de (8.12.8/8.12.8) with ESMTP id
 h24GQ2aG031749
	for <cocoon-dev@xml.apache.org>; Tue, 4 Mar 2003 17:26:02 +0100
Received: from bremen.dvs1.informatik.tu-darmstadt.de (bremen [130.83.27.69])
	by paris (Postfix) with ESMTP id E742DFF0A
	for <cocoon-dev@xml.apache.org>; Tue,  4 Mar 2003 17:26:01 +0100 (MET)
Received: from haul by bremen.dvs1.informatik.tu-darmstadt.de with local (Exim
 3.36 #1 (Debian))
	id 18qFEv-0006Yz-00
	for <cocoon-dev@xml.apache.org>; Tue, 04 Mar 2003 17:26:01 +0100
Date: Tue, 4 Mar 2003 17:26:01 +0100
To: cocoon-dev@xml.apache.org
Subject: Re: big ESQL performance problem - this one's weird
Message-ID: <20030304162601.GK24538@bremen.dvs1.informatik.tu-darmstadt.de>
Reply-To: haul@informatik.tu-darmstadt.de
References: <20030304135522.GA32052@kompuart.pl>
 <36490.10.0.0.1.1046787145.squirrel@ags01.agsoftware.dnsalias.com>
 <20030304150818.GA2943@kompuart.pl>
 <20030304152509.GJ24538@bremen.dvs1.informatik.tu-darmstadt.de>
 <20030304155911.GA7821@kompuart.pl> <3E64CED1.9050004@dff.st>
 <20030304161124.GB7821@kompuart.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030304161124.GB7821@kompuart.pl>
Organization: Databases and Distributed Systems Group,
 Darmstadt University of Technology
User-Agent: Mutt/1.5.3i
From: Christian Haul <haul@dvs1.informatik.tu-darmstadt.de>
X-MailScanner: Found to be clean
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On 04.Mar.2003 -- 05:11 PM, Leszek Gawron wrote:
> On wto, mar 04, 2003 at 05:05:37 +0100, Torsten Curdt wrote:
> > >while trying to test the esql:get-object I have run just this:
> > ><esql:execute-query>
> > >	<esql:query>
> > >		SELECT * from kontrah</esql:query>
> > >		<esql:results>
> > >			<esql:row-results><a></a></esql:row-results>
> > >		</esql:results>
> > ></esql:execute-query>
> > >
> > >The execution time does not differ much from first case even though I do 
> > >not do any esql-getXXX.
> > 
> > Not weird at all!
> > You are still looping through the ResultSet (row-results)
> Yes but some people in this discussion blamed the amount of SAX events to
> handle for bad performance. So now it is clear that it's the rowset traversal
> that consumes so much CPU, but still why? I'm not skilled in JDBC. The only
> difference I can tell from Squirell SQL client is that it does not use prepared
> statements.

If you have a <esql:parameter .../> in your query, esql uses a
prepared statement. Otherwise it won't.

Another interesting point would be to restrict the data retrieved by
using "select some_column from kontrah" instead of "select * from kontrah" 
Might have a performance impact depending on how smart the driver is.

Other things that might apply are options to the jdbc driver on cache
/ transfer size, isolation modes etc. 

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08