On 14 Nov 2012 05:23, Gad Miron wrote:
2. while looking at CHGPF/CHGLF CMDs I noticed a
KEEPINMEM(*SAME/*NO/*YES) parameter I haven't noticed before.
Is it new to 7.1 ?
Seems so; FWiW:
The last sentence in that message assumes prior knowledge of the
discussion thread, particularly what is responded to in the message:
Is it equivalent/substitute/enhancement to SETOBJACC ?
The SETOBJACC allows a /user/ to request\attempt to move into memory
the object\data. The /user/ has the capability to assign the pool to
avoid the Storage Management from purging the objects and\or data from
The Keep In Memory parameter is apparently specific to the SQL Query
Engine (SQE), and there is only Query INI [via CHGQRYA QRYOPTLIB()]
capability to control which pool; i.e. not specific to any file. Any
non-SQE utilization of the data would benefit only as a side effect of
any prior /bring/ [paging] request effected by the SQE, and only if the
data had not been paged out already.
The SQE can optimize for use of an "already paged" Access Path or
Data [Dataspace] by building an Access Plan which can take advantage of
that knowledge. I imagine that the KeepInMem attribute is a hint to the
SQE to perform explicit [synchronous or asynchronous] paging of an
Access Path or the Data [Dataspace] when implementing the query, after
having built the plan which inferred the "already paged" is in effect.
An additional possible effect might be that the SQE would not request an
asynchronous release\purge when that KeepInMem attribute is in effect,
for any scenario in which that might normally have been done; e.g. for
an especially memory aggressive implementation.?
Isn't it actually unnecessary once you have a SSD unit?
Irrespective of Single-Level-Storage, Disk and Memory remain
different. The Solid State Drive is still a drive, just as a spinning
Hard Disk Drive is, and paging from /Drives/ into memory will still
occur whether that be via faulting or by explicit /bring/ request. So
while a particular SSD may perform faster for a read than a particular
spinning HDD, the code path is effectively the same to get that data,
and the memory\Storage Management to share the memory among all work is
still going to be a point of contention. Any improved throughput would
be expected to reduce chances that such work will be a bottleneck.