Re: Using SSD with IBMi V7R1

[CRPence <CRPbottle@xxxxxxxxx>]

On 14 Nov 2012 05:23, Gad Miron wrote:
> <<SNIP>>
>
> 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:
http://archive.midrange.com/rpg400-l/201111/msg00094.html

  The last sentence in that message assumes prior knowledge of the 
discussion thread, particularly what is responded to in the message:
http://archive.midrange.com/rpg400-l/201111/msg00114.html

>      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 
that pool.

  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.