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:
BTreeForwardScan
BTreeScan
BTreeController
GenericScanController
HeapCompressScan
HeapScan
(OpenConglomerate - part of a method that is never called;
debugConglomerate)
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 :)
regards,
--
Kristian
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,
