<?xml version="1.0" encoding="utf-8"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>Actian Community Forums - Blogs - zelaine</title>
		<link>http://community.actian.com/forum/blogs/zelaine/</link>
		<description><![CDATA[Actian Corporation is a leading provider of open source database management software and support services. [Toll Free] +1 (888) 446-4737]]></description>
		<language>en</language>
		<lastBuildDate>Wed, 22 Feb 2012 22:24:35 GMT</lastBuildDate>
		<generator>vBulletin</generator>
		<ttl>60</ttl>
		<image>
			<url>http://community.actian.com/forum/ingres4/misc/rss.jpg</url>
			<title>Actian Community Forums - Blogs - zelaine</title>
			<link>http://community.actian.com/forum/blogs/zelaine/</link>
		</image>
		<item>
			<title>Ingres 10 Features</title>
			<link>http://community.actian.com/forum/blogs/zelaine/64-ingres-10-features.html</link>
			<pubDate>Tue, 06 Apr 2010 00:13:59 GMT</pubDate>
			<description>The  Ingres 10 roadmap page (http://community.ingres.com/wiki/Ingres_Roadmap/10) has a full list of features planned for that release.  In this blog...</description>
			<content:encoded><![CDATA[<div>The  <a href="http://community.ingres.com/wiki/Ingres_Roadmap/10" target="_blank">Ingres 10 roadmap page</a> has a full list of features planned for that release.  In this blog entry, I thought I would provide a high level overview of some of the key features.<br />
<ul><li> <a href="http://community.ingres.com/wiki/MVCC" target="_blank">MVCC</a> - Today, Ingres implements concurrency control by using locking.  Different granularities of locking are available, which can alleviate conflicts due to locking.  But even when row level locking is used, there's still the potential for readers to block writers and vice versa, if the readers need to read consistent, committed data rows that the writers are accessing at the same time.  MVCC provides an alternative to locking by using a log-based approach to, on the fly, reconstruct earlier versions of committed data.  By avoiding application hangs that you would otherwise encounter if users are waiting on locks held by other users, you end up with improved concurrency.  If you prefer pictures over words :), see these <a href="http://community.ingres.com/w/files/2/24/MVCC.pdf" target="_blank">slides</a>.<br /></li>
<li> <a href="http://community.ingres.com/wiki/Scalar_Subqueries" target="_blank">Scalar Subqueries</a> - Ingres today supports scalar subqueries, but only in a limited context; namely, only in the WHERE, ON, or HAVING clause of queries.  In Ingres 10, support will be extended to other contexts where expressions are allowed.  E.g., they will be allowed in the projection list of a SELECT, the VALUES clause of an INSERT, the SET clause in an UPDATE, and within a CASE expression.  This will alleviate application developers from having to rewrite their queries to avoid using scalar subqueries.<br /></li>
<li> <a href="http://community.ingres.com/wiki/Long_Identifiers" target="_blank">Long Identifiers</a> - Ingres object names are currently limited to 32 bytes.  This can be problematic for applications that auto-generate names, as those auto-generated names can spill pass 32 bytes, requiring a conversion step<br />
to make the application work with Ingres.  Ingres 10 raises this limit to 256 bytes for most object types.  Exceptions are things like database, location, and user names, which typically do not exceed 32 bytes.<br /></li>
<li><a href="http://community.ingres.com/wiki/Batch_Statement_Execution_Performance" target="_blank">Batched Statement Execution</a> - JDBC provides an interface for executing a series of statements in a <i>batch</i>, which the Ingres JDBC driver currently does support.  However, the implementation is such that the individual statements within the batch are still executed in a series of round trip messages between the client and server, i.e., one round trip per statement within the batch.  In Ingres 10, this will be optimized so there's only a single round trip message per batch, reducing client-server communication traffic and improving performance.  In addition, because users typically also use this batch interface to bulk load data, the implementation will be further optimized for that particular use case.  One such optimization converts the series of inserts into an equivalent Ingres COPY statement, allowing the batch execution to benefit from the bulk load code paths used by COPY.<br /></li>
<li><a href="http://community.ingres.com/wiki/Bulk_Loading_Projects" target="_blank">Bulk Load Performance</a> - This project is targeted at improving the performance of the Ingres COPY statement.  A number of improvements have already been made, and they are described on <a href="http://community.ingres.com/wiki/Bulk-Load_Performance_Study" target="_blank">this page</a>.  As noted in the table on that page, a load of 4.5 million rows into a TPC-H LINEITEM table that used to take 1 minute 18 seconds, now completes in 21 seconds, as of March 31st.  (Community edition build 120 includes the changes that resulted in that timing.)  As with any performance numbers, your mileage will vary.  But for that particular case, that's a 3.7x improvement!  In addition to improving performance, one additional change that Karl Schendel sneaked in as part of reworking the frontend COPY code in order to achieve the performance gains noted, is he added support for CSV input files.  That means that you're no longer limited to using VDBA import assistant to load data exported from your Excel spreadsheets.  In addition, for countries (e.g., Germany) where comma instead of dot is used as a decimal separator, semi-colon separated values input files are also supported.  See the <a href="http://community.ingres.com/wiki/Bulk_Loading_Projects#Documentation" target="_blank">documentation link</a> for details on the syntax to use in your COPY statements.<br /></li>
<li><a href="http://community.ingres.com/wiki/Ingres_Director_Home" target="_blank">New Admin Tools</a> - The goal of this project is to build a single GUI interface for our database administration tools, across all platforms.  The tool will provide a single interface from which all database admin functions can be initiated.  It will be a GUI alternative to existing command line and form-based tools.  For a more in-depth overview of the project, see the project page for a link to a presentation and video recording of the presentation.<br /></li>
<li><a href="http://community.ingres.com/wiki/Data_at_Rest_Encryption" target="_blank">Data Encryption</a> - With this feature, data <i>at rest</i> will be encrypted.  This essentially means that data will be encrypted when it's written out to disk, as opposed to when it's passed over the network between the DBMS and the client application.  Data encryption is important for PCI DSS and HIPAA compliance. The encryption will be done using private key, AES encryption.<br />
</li>
</ul>MVCC, Scalar Subqueries, Long Identifiers, and Bulk Load optimizations are currently available for testing in community edition builds.  If I've piqued your interest, feel free to download a community edition build and give the features a test spin.  Other features denoted by the lady bug icon on the roadmap page are also available for early testing.<br />
<br />
Batch Statement Execution will be available in the upcoming community edition build 121, which will be available for download later this week.  Keep an eye on the roadmap page for availability of other features.</div>

]]></content:encoded>
			<dc:creator>zelaine</dc:creator>
			<dc:publisher>13865</dc:publisher>
			<guid isPermaLink="true">http://community.actian.com/forum/blogs/zelaine/64-ingres-10-features.html</guid>
		</item>
	</channel>
</rss>

