Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 2163 invoked by uid 500); 5 Mar 2003 08:42:04 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 2147 invoked from network); 5 Mar 2003 08:42:04 -0000 Received: from unknown (HELO mail.dff.local) (62.159.19.130) by daedalus.apache.org with SMTP; 5 Mar 2003 08:42:04 -0000 Received: from altair.dff.local ([172.16.2.8] helo=dff.st) by mail.dff.local with esmtp (Exim 3.35 #1) id 18qUTf-0002ZY-00 for cocoon-dev@xml.apache.org; Wed, 05 Mar 2003 09:42:15 +0100 Message-ID: <3E65B89A.80005@dff.st> Date: Wed, 05 Mar 2003 09:43:06 +0100 From: Torsten Curdt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: big ESQL performance problem - this one's weird References: <20030304152509.GJ24538@bremen.dvs1.informatik.tu-darmstadt.de> <20030304155911.GA7821@kompuart.pl> <3E64CED1.9050004@dff.st> <20030304161124.GB7821@kompuart.pl> <20030304162601.GK24538@bremen.dvs1.informatik.tu-darmstadt.de> <20030304164445.GB10285@kompuart.pl> <20030304171131.GA25711@bremen.dvs1.informatik.tu-darmstadt.de> <3E64F010.5090608@dff.st> <20030304212437.GB14460@kompuart.pl> <1046823387.936.33.camel@defiant.dff.local> <20030305075243.GB20894@kompuart.pl> In-Reply-To: <20030305075243.GB20894@kompuart.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Leszek Gawron wrote: > On śro, mar 05, 2003 at 01:16:26 +0100, Torsten Curdt wrote: > >>So you think cocoon should fix all the bugs that software vendor X >>refuses to fix? come on! > > I have the "pervasive case" in my mind and was reffering to that. I think it's > not even a bug (that awful performance) but the way they have designed the SQL > layer on Btrieve DB - you have to use it in a specific way to get your results > quite fast or you won't get them at all. It's a matter of cocoon if it will > support the database or not. ...well, so you ask for a per database behaviour of esql. Doable but not done yet. Hm... Chris, what do you think about creating a full featured database abstraction layer? -- Torsten