db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: "dynamic_info" in the access layer
Date Thu, 08 Mar 2007 16:44:39 GMT
Mike Matrigali wrote:
> 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.

Thank you for the information Mike.

Studying the code a bit more, it seems this mechanism is used in the 
following six classes from three different packages:
  (OpenConglomerate - part of a method that is never called; 

When I search for the usage of DynamicCompiledOpenConglomInfo, I find 
107 occurrences, spread out in ten difference packages and quite a few 
files (30+). In many of these, null is passed in explicitly. This is why 
I reacted a bit on this code, as I was not able to quickly see the 
advantage of it.

I have done some minor cleanup (removing an unused method and variable 
++) in OpenConglomerateScratchSpace, but will not try to do anything 
else at the moment.
When it comes to BTree scans, it seems a new 
OpenConglomerateScratchSpace-object is created for each scan. In some of 
the classes the use of the object is within loops, so I can clearly see 
the point of this optimization when the scan is touching a lot of records.

If you feel there is room for improvements in this space, it wouldn't 
hurt to say so. Maybe someone picks it up later :)


> 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,

View raw message