Re: RSAM
Frank asked about RSAM, citing a paper describing it as a published, row-at-a-time storage API and wondering why JDBC examples seemed to show RSAM calls. Marco Greco explained that rs.next() is simply a JDBC ResultSet method, not an RSAM call, and that the quoted paper likely misuses the acronym (SQLI would be more accurate). John Miller and Dick Snoke noted a C-ISAM DataBlade exists, but it exposes C-ISAM files as tables rather than giving C-ISAM-style access to IDS; RSAM is not a public C-ISAM-like interface. No change or workaround was offered for migrating C-ISAM apps, with Frank ending by lamenting the lack of upward compatibility.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
How come INFORMIX-JDBC has examples of RSAM calls like for rs.next()?, and "...IDS is divided into two parts: a storage manager called RSAM, and a query optimization/execution engine implemented on top of RSAM, and has a well-defined, published API...Implementing Index Stride above RSAM resulted in some compromises in performance. RSAM presents interfaces for scanning relations, and for fetching rows from indexes. The index-based interface to RSAM takes as arguments a relation R, an index I , and a predicate p, and returns rows from R that match p. To amortize I/O costs, an efficient implementation of Index Stride would fetch rows a disk block at a time: one block of rows from the first group, then one from the second, and so on. Since the RSAM interface is row-at-a-time, there is no way to explicitly request a block of rows. In principle the buffer manager could solve this problem by allocating a buffer per group: then when fetching the first row from a block it would put the block in the buffer pool, and it would be available on the next fetch. Unfortunately this buffering strategy does not correspond naturally to the replacement policies in use in a traditional DBMS. The performance of Index Stride could be tuned up by either implementing a page-based Index Stride in RSAM, or enhancing the buffer manager to recognize and optimize Index Stride-style access."
FRANK@ FRANKCOMPUTER.COM wrote: > How come INFORMIX-JDBC has examples of RSAM calls like for rs.next()?, > > and > > "...IDS is divided into two parts: a storage manager called RSAM, and > a query optimization/execution engine implemented on top of RSAM, and has a > well-defined, published API...Implementing Index Stride above RSAM resulted in > some compromises in performance. RSAM presents interfaces for scanning > relations, and for fetching rows from indexes. The index-based interface to > RSAM takes as arguments a relation R, an index I , and a predicate p, and > returns rows from R that match p. To amortize I/O costs, an efficient > implementation of Index Stride would fetch rows a disk block at a time: one > block of rows from the first group, then one from the second, and so on. Since > the RSAM interface is row-at-a-time, there is no way to explicitly request a > block of rows. In principle the buffer manager could solve this problem by > allocating a buffer per group: then when fetching the first row from a block > it would put the block in the buffer pool, and it would be available on the > next fetch. Unfortunately this buffering strategy does not correspond > naturally to the replacement policies in use in a traditional DBMS. The > performance of Index Stride could be tuned up by either implementing a > page-based Index Stride in RSAM, or enhancing the buffer manager to recognize > and optimize Index Stride-style access." > Informix jdbc demos most definitely do not have examples of RSAM calls. Typically next() would be a method of a ResultSet object, whose scope in life is to get the next row from that particular result set. In the example cited (and note that it is never a good idea to take too little information, show it out of context and ask info about it) I would venture to guess that rs is the name of a ResultSet object instance, named rs, because it happens to be an acronym for result set... In terms of the index stride quote - again that's too little a snippet to give any definite answer, but my guess would be that the author is misusing acronyms (aside from having little knowledge of the RSAN architecture - which does not store rows in disk blocks). SQLI should have been used in place of RSAM. -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm
correct about the rs = result set, nowever, the author stated RSAM uses "row-at-a-time" and is suggesting "block-at-a-time" capability. Too bad IBM/INFORMIX is not making at least the basic RSAM storage management libraries available to developers. That means that any app's using C-ISAM calls in SE would have to be re-written with I4GL or ESQL/C in order to migrate to IDS, plus loosing the ability to write low-level functions like the "Look-Ahead result-set before Query completes".
There was a C-ISAM datablade which allowed C-ISAM function to access IDS directly. John F. Miller III STSM, Support Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 04/07/2010 10:50:52 AM: > [image removed] > > Re: RSAM [19552] > > FRANK@FRANKCOMPUTER.COM > > to: > > ids > > 04/07/2010 10:52 AM > > Sent by: > > ids-bounces@iiug.org > > Please respond to ids > > correct about the rs = result set, nowever, the author stated RSAM uses > "row-at-a-time" and is suggesting "block-at-a-time" capability. Too bad > IBM/INFORMIX is not making at least the basic RSAM storage management > libraries available to developers. That means that any app's using C-ISAM > calls in SE would have to be re-written with I4GL or ESQL/C in order to > migrate to IDS, plus loosing the ability to write low-level > functions like the > "Look-Ahead result-set before Query completes". > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
Hi, From the discussion thread, it sounds to me like the original request was for a set of functions, ala C-ISAM, to directly access relational data instead of using SQL. In my opinion, the writer does not appreciate the difference between ISAM files and relational storage. Those are very different things and the set of functions in RSAM is not very much like the simple C-ISAM interface. Any C-ISAM program would have to be re-written and would become far more complex if the RSAM storage manager is used directly. One of the good things about SQL is to simplify that interface. Just my opinions. Don't take them as representing anything else. The C-ISAM datablade still exists. The purpose of that blade is to make Informix C-ISAM (not anyone else's ISAM) files appear as tables in a relational database. That's the opposite of the original requuest, I think. Cheers, Dick Snoke Executive IT Specialist IBM Software Group - ChannelWorks Tel: (404) 487-1595 Email: dsnoke@us.ibm.com From: John Miller iii/Menlo Park/IBM@IBMUS To: ids@iiug.org Date: 04/07/10 03:59 PM Subject: Re: RSAM [19558] Sent by: ids-bounces@iiug.org There was a C-ISAM datablade which allowed C-ISAM function to access IDS directly. John F. Miller III STSM, Support Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 04/07/2010 10:50:52 AM: > [image removed] > > Re: RSAM [19552] > > FRANK@FRANKCOMPUTER.COM > > to: > > ids > > 04/07/2010 10:52 AM > > Sent by: > > ids-bounces@iiug.org > > Please respond to ids > > correct about the rs = result set, nowever, the author stated RSAM uses > "row-at-a-time" and is suggesting "block-at-a-time" capability. Too bad > IBM/INFORMIX is not making at least the basic RSAM storage management > libraries available to developers. That means that any app's using C-ISAM > calls in SE would have to be re-written with I4GL or ESQL/C in order to > migrate to IDS, plus loosing the ability to write low-level > functions like the > "Look-Ahead result-set before Query completes". > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
>"From the discussion thread, it sounds to me like the original request was >for a set of functions, ala C-ISAM, to directly access relational data >instead of using SQL...In my opinion, the writer does not appreciate the >difference between ISAM files and relational storage. Those are very >different things and the set of functions in RSAM is not very much like >the simple C-ISAM interface." To access C-ISAM, C-RSAM, R-tree or whatever your'e calling the file-structure within IDS these days, not any other non-IDS ISAM file. The fact remains that any app's written with C-ISAM calls or using "include isam.h" have to be converted to use SQL statements, and for many years, they're plenty of those around still running, plus the loss of ability to write low-level functions..I consider it to be a strategic blunder to "black-box" RSAM by not providing any upward compatibility. Another reason why perhaps many Informix legacy apps will remain the way they are!