Hi Stefan, It seems that at least the bundle select statement:
"select BUNDLE_DATA from " + schemaObjectPrefix + "BUNDLE where NODE_ID = ?" causes a full table scan. We're using Jackrabbit 1.3 with the patch for JCR-940. This patch also uses stmt.setBytes. Best regards, Martijn -- Martijn Hendriks <GX> creative online development B.V. t: 024 - 3888 261 f: 024 - 3888 621 e: [EMAIL PROTECTED] Wijchenseweg 111 6538 SW Nijmegen http://www.gx.nl/ > -----Original Message----- > From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] > Sent: Friday, August 31, 2007 12:34 PM > To: [email protected] > Subject: Re: Oracle does not use index on NODE_ID column > > hi martijn, > > On 8/31/07, Martijn Hendriks <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > We've noticed that some queries with the oracle bundle persistence > > manager are very slow (an order of magnitude slower than with MSSQL > > for instance). This seems to be due to an implicit > conversion from a > > raw value to a varchar2 which disables the index (see > > http://orafaq.com/maillist/oracle-l/2007/02/14/1050.htm). > > i don't think that those issues are related. with the oracle > bundle persistence there should be no implicit conversion > from raw to varchar2 since the stmt parameter is bound as byte[], i.e. > > stmt.setBytes(pos++, uuid.getRawBytes()); > > which statements are affected? > > > > > Would it be possible to use the suggested HEXTORAW > function, or does > > that have unwanted side effects? > > > > I.e., use "select BUNDLE_DATA from " + schemaObjectPrefix + "BUNDLE > > where NODE_ID = HEXTORAW(?)"; > > IMO that wouldn't do any good, see above. > > cheers > stefan > > > > > Best regards, > > > > Martijn > > > > > > -- > > > > Martijn Hendriks > > <GX> creative online development B.V. > > > > t: 024 - 3888 261 > > f: 024 - 3888 621 > > e: [EMAIL PROTECTED] > > > > Wijchenseweg 111 > > 6538 SW Nijmegen > > http://www.gx.nl/ > > >
