We announced today that Ingres 9.2 is now Generally Available and as you can see from the press release, we’ve put this release through its paces to ensure that its truly enterprise ready. The release includes a myriad of features that were requested by my Icebreaker Appliance team which we’re excited about, but my own personal favorite “feature” is that we’ve finally corrected the version numbering. Gone is 2006 (30 lashes with a wet noodle for the marketing team that decided that was a good idea) and in its place a return to a more traditional naming that will match the internal version number. Now, my excitement about the naming may be a little overstated, but you should understand that we’ve been making use of the 9.2 features in the appliances since the moment coding ended earlier this year, so as you’re getting excited about 9.2 we’re already salivating over the 9.3 feature set because the innovation at Ingres never stops.

Internally the database has always honored the original numbering scheme.  My first hands-on experience with Ingres was with version 5 back in the late 80s.  Externally ASK reset the version number to 1 right after its acquisition of the technology.  In a complete departure from the previous naming/numbering, Ingres Corp launched Ingres 2006 in February 2006.  Inserting a year in a product name immediately dates it, but given that the open source model enables us to release often we didn’t think that would pose a problem to us and we could release Ingres 2007, Ingres 2008 etc.  What we hadn’t considered is that changing the product name would result in partners having to recertify their applications and customers having to go through a more rigorous process to put the product into production than if we rolled a minor version number.  So to keep things simple the product name is “Ingres Database” and the version number is 9.2   For clarity, Ingres 2006 had an internal version number of 9.0 and Ingres 2006 release 2 had an internal version number of 9.1.  The next minor release, due to go beta early next year, will be 9.3 and the next major release will be 10.

So, what’s new in 9.2?  Let me start with the features my team requested

• Scrollable Cursors – Scrollable cursors are database query result sets that are maintained in the database server as long as the cursor is open and that allow the user to retrieve rows of a result set in any sequence.   Scrollable cursors greatly ease the display of information, for example, in scrolling web applications and enable the application to move backward and forward through the query results faster.
• LOB (Large Object) Locators – Ingres 9.2 adds support for LOB locators in compliance with the ANSI SQL 2003 standard. LOB locators, which may be used with BLOBs and CLOBs, are pointers to the LOB data and greatly reduce the network traffic passed between the client and server. They permit the client to access LOB data outside the scope of row data retrieval, so that the client application can control the processing and storage requirement of the LOB data.
• Improved Out of the Box Defaults – Ingres 9.2 has new defaults for a series of configuration parameters including the default page size and the default buffer cache size.  We’ve also increased the default size for a transaction log file from 32MB to 256MB.   These changes increase the chances of a non-educated new user being successful with Ingres 9.2 out of the box.  We’ve also added the ability to change the default table structure from a heap to a btree (see below) which again is intended to improve the chances of a novice Ingres user being successful out of the box.
• Automatic Storage Structure for New Tables – The storage structure of a base table, when created, is automatically determined based on the syntax used for the CREATE TABLE statement. If the CREATE TABLE statement includes at least a primary key, unique constraint, or referential (foreign key) constraint, the base table structure is set to B-tree and the usual secondary index is not built.   If the table definition includes more than one constraint, it chooses the primary key constraint over a unique constraint, and the first unique constraint over any referential constraint. Previously, all new tables were created with a heap structure, by default.   This feature is enabled or disabled in a given DBMS Server by setting the configuration parameter table_auto_structure to ON or OFF.
• New SQL Functions – To simplify the migration of applications built for other database technologies we’ve added a whole host of new SQL functions including the following: round, ceiling,  floor, truncate, atan2, acos, asin, tan, pi, sign, chr, ltrim, rtrim, lpad, rpad and replace as well as adding the ability to invoke the upper and lower functions on Unicode datatypes which was a requirement for certifying Jaspersoft with Ingres.
• Cached Dynamic Cursor Query Plans – When doing performance benchmarking with Jaspersoft we identified a need to cache and reuse query plans for cursors defined with dynamic SELECT statements so that when a subsequent PREPARE is executed on the identical syntax, the query plan in cache is used and the query is not re-optimized.  I suspect that this will have much broader applicability, and in fact I know that Durwin Wright from our OpenROAD team was excited by this addition.

I’m doing the engineering team a disservice in calling out particular features so I’d like to invite you to view the Ingres 9.2 Release Summary at http://esd.ingres.com/product/docs/Ingres_9.2/docs/Individual_Guides/Ing_RelSum.pdf/http

 

 Tags: 9.2, Database, Ingres

 Posted in Database, Innovation

This entry was posted on Tuesday, November 18th, 2008 at 5:01 am and is filed under Database, Innovation. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.