Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45EEF6E1.4020306@sbcglobal.net>
Date: Wed, 07 Mar 2007 09:31:13 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: "dynamic_info" in the access layer
References: <45EE9221.9040703@Sun.com>
In-Reply-To: <45EE9221.9040703@Sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I believe this is still actively used.  It's main purpose is to save
memory allocation/deallocation in statements that are executed more
than once.  I believe the plan was to make more extensive use of it,
but as you have seen it is limited.

The problem is that the caller of store is the one that is set up to
save memory across executions of a statement, so it needs to own this
memory.  But the actual objects are private to store, thus why the
interface looks strange, it is set up so that in the future store if
necessary can put more or less into this private space.  While there
may be few in code number, I believe that openCompiledScan is the way
most user executed query's get run in the store.  The savings here
is that select executed 1 million times can only allocate a buffer
once rather than 1 million times.  It is trying to do the same thing
for store working memory as is done in the language layer for query
plan dynamic memory.


Kristian Waagan wrote:
> Hello,
> 
> This information in this mail is rather incomplete.
> However, I have been looking at the access layer lately, trying to get 
> an overview over the code. I do not quite understand the use of 
> "dynamic_info", or more precisely if it is still used a lot.
> 
> dynamic_info is an object implementing the interface 
> DynamicCompiledOpenConglomInfo. The interface has no methods or fields. 
> The only implementing class I have found, is 
> OpenConglomerateScratchSpace. The methods in this class are being 
> called, but I have not checked out from where.
> 
> I have found only two casts from the interface to the implementing 
> class. In both cases a new instance of OpenConglomerateScratchSpace will 
> be created of the passed in dynamic_info is null.
> In both cases, the OpenConglomerateScratchSpace is assigned to 
> this.runtime_mem (in OpenConglomerate and in OpenBTree). At least some 
> methods in OpenConglomerateScratchSpace is called by getting the 
> reference stored in runtime_mem, which may or may not come from the 
> dynamic_info variable.
> 
> 
> My question is, will the passed in dynamic_info ever be non-null?
> Is this a left-over from earlier days, or is the usage still a crucial 
> part of the access layer?
> 
> If not, the passing of this variable clutters the code. I can observe 
> that a null is passed explicitly in very many places where methods 
> accept a DynamicCompiledOpenConglomInfo reference.
> I plan to check this at runtime, but if anyone already has the answer, 
> it would be convenient :)
> 
> 
> 
> thanks,