Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Wed, 29 Nov 2006 15:56:23 +0100
From: Dyre.Tjeldvoll@Sun.COM
Subject: Re: ArrayInputStream and performance
In-reply-to: <456C726B.3000003@sbcglobal.net>
Sender: Dyre.Tjeldvoll@Sun.COM
To: derby-dev@db.apache.org
Cc: mikem_app@sbcglobal.net
Message-id: <x1o3mz6al2so.fsf@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <x1o3k61mo4gs.fsf@sun.com> <wjo8wt5l9m8m.fsf@sun.com>
 <456B917F.4090706@apache.org> <wjo8r6vn501x.fsf@sun.com>
 <456C726B.3000003@sbcglobal.net>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (usg-unix-v)

Mike Matrigali <mikem_app@sbcglobal.net> writes:


> It would be fine to use an unchecked and/or an ASSERT based check for
>  readFieldLengthAndSetStreamPosition.  The "store" module owns this
> access and is not counting on limit checks to catch anything here.

Another question:

All observed calls to setLimit (single tuple select load) come from the same
method: StoredPage.readRecordFromArray(...) 
(setLimit is also called from readRecordFromStream() but this does not
seem to happen with this type of load)

And the argument to setLimit()is always the local variable fieldDataLength
which is the return value from
StoredFieldHeader.readLengthAndSetStreamPosition().

So if readLengthAndSetStreamPosition() can update the position without
checking, presumably the return value from this method can be trusted
as well? Is it then necessary to check this value again in setLimit(),
or could we have used an unchecked version of setLimit here?
  
-- 
dt