MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » November 2012

Re: Using SSD with IBMi V7R1



fixed

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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact