Ingres (database)
View on Wikipedia| Ingres | |
|---|---|
| Original authors | University of California, Berkeley |
| Developer | Actian |
| Stable release | 12.0
/ July 14, 2024[1] |
| Written in | C |
| Operating system | Cross-platform |
| Type | RDBMS |
| License | Proprietary, used to be open source GNU General Public License |
| Website | www |
Ingres Database (/ɪŋˈɡrɛs/ ing-GRESS) is a proprietary SQL relational database management system intended to support large commercial and government applications.
Actian Corporation controls the development of Ingres and makes certified binaries available for download, as well as providing worldwide support. There was an open source release of Ingres but it is no longer available for download from Actian. However, there is a version of the source code still available on GitHub.[2]
In its early years, Ingres was an important milestone in the history of database development. Ingres began as a research project at UC Berkeley, starting in the early 1970s and ending in 1985.[3] During this time Ingres remained largely similar to IBM's seminal System R in concept; it differed in more permissive licensing of source code, in being based largely on DEC machines, both under UNIX[4] and VAX/VMS,[5] and in providing QUEL as a query language instead of SQL. QUEL was considered at the time to run truer to Edgar F. Codd's relational algebra (especially concerning composability), but SQL was easier to parse and less intimidating for those without a formal background in mathematics.[6]
When ANSI preferred SQL over QUEL as part of the 1986 SQL standard (SQL-86), Ingres became less competitive against rival products such as Oracle until future Ingres versions also provided SQL.[7] Many companies spun off of the original Ingres technology, including Actian itself, originally known as Relational Technology Inc., and the NonStop SQL database originally developed by Tandem Computers but now offered by Hewlett Packard Enterprise.
History
[edit]Ingres began as a research project at the University of California, Berkeley, starting in the early 1970s and ending in 1985.[3] The original code, like that from other projects at Berkeley, was available at minimal cost under a version of the BSD license. Ingres spawned a number of commercial database applications, including Sybase, Microsoft SQL Server, NonStop SQL and a number of others.[8]
Postgres (Post Ingres), a project which started in the mid-1980s,[9] later evolved into PostgreSQL. It is ACID compatible and is fully transactional (including all DDL statements) and is part of the Lisog open-source stack initiative.
1970s
[edit]In 1973 when the System R project led by Edgar Codd was getting started at IBM, the research team released a series of papers describing the system they were building.[8] Two scientists at Berkeley, Michael Stonebraker and Eugene Wong, became interested in the concept after reading the papers, and started a relational database research project of their own.[10][11][12]
They had already raised money for researching a geographic database system for Berkeley's economics group, which they called Ingres, for INteractive Graphics REtrieval System. They decided to use this money to fund their relational project instead, and used this as a seed for a new and much larger project. They decided to re-use the original project name, and the new project became University INGRES.[10] For further funding, Stonebraker approached the DARPA, the obvious funding source for computing research and development at the time, but both the DARPA and the Office of Naval Research (ONR) turned them down[13] as they were already funding database research elsewhere. Stonebraker then introduced his idea to other agencies, and, with help from his colleagues he eventually obtained modest support from the NSF[14] and three military agencies: the Air Force Office of Scientific Research, the Army Research Office, and the Naval Electronic Systems Command.
Thus funded, Ingres was developed during the mid-1970s by a rotating team of students and staff. Ingres went through an evolution similar to that of IBM System R, with an early prototype in 1974 followed by major revisions to make the code maintainable. Ingres was then disseminated to a small user community, and project members rewrote the prototype repeatedly to incorporate accumulated experience, feedback from users, and new ideas. The research project ended in 1985.[3]
Commercialization (1980s)
[edit]Ingres remained largely similar to IBM's System R in concept, but it was based largely on DEC machines running Unix.[4] Unlike System R, Ingres benefited from Unix's growing popularity and was available for free;[11] source code was available (on tape) for a nominal fee. By 1980 some 1,000 copies had been distributed,[15] primarily to universities. Many students from Berkeley and other universities who used the Ingres source code worked on various commercial database software systems.
Many asked when Ingres would become a commercial product. After hearing that Larry Ellison was comparing the Oracle Database to Ingres, the project formed a commercial company, borrowed university computers in exchange for a free license, and ported the database from Unix to VAX VMS. The first product release occurred in early 1981; among the customers were DEC and Schlumberger. Demand for the VMS version was so much stronger than on Unix that the company neglected the latter and had to port the software back to it.[12]
Berkeley students Jerry Held and later Karel Youseffi moved to Tandem Computers, where they built a database system that evolved into NonStop SQL. The Tandem database system was a re-implementation of the Ingres technology.[16] It evolved into a system that ran effectively on parallel computers; that is, it included functionality for distributed data, distributed execution, and distributed transactions (the last being fairly difficult). Components of the system were first released in the late 1970s. By 1989, the system could run queries in parallel and the product became fairly famous for being one of the few systems that scales almost linearly with the number of processors in the machine: adding a second CPU to an existing NonStop SQL server will almost exactly double its performance. Tandem was later purchased by Compaq, which started a re-write in 2000, and now the product is at Hewlett-Packard Enterprise.
In the early 1980s, Ingres competed head-to-head with Oracle,[17] but IBM's endorsement of SQL benefited Oracle.[18] The two products were widely regarded as the leading hardware-independent relational database implementations; they had comparable functionality, performance, market share, and pricing, and many commentators considered Ingres to be a (perhaps marginally) superior product. From around 1985, however, Ingres steadily lost market share. One reason was Oracle's aggressive marketing; another was the increasing recognition of SQL as the preferred relational query language. Ingres originally had provided a different language, QUEL, and the conversion to SQL (delivered in Ingres version 6) took about three years, losing valuable time in the race.
Robert Epstein, the chief programmer on the project while he was at Berkeley, formed Britton Lee, Inc.[19] along with other students from the Ingres Project, Paula Hawthorn and Michael Ubell; they were joined later by Eric Allman. Later, Epstein founded Sybase. Sybase had been the #2 product (behind Oracle) for some time through the 1980s and into the 1990s, before Informix came "out of nowhere" and took over in 1997. Sybase's product line had also been licensed to Microsoft in 1992, who rebranded it as Microsoft SQL Server. This relationship soured in the late 1990s, and today SQL Server outsells Sybase by a wide margin.
Relational Technologies, Inc. (RTI)
[edit]Several companies used the Ingres source code to produce products. The most successful was a company named Relational Technology, Inc. (RTI), founded in 1980 by Stonebraker and Wong, and another Berkeley professor, Lawrence A. Rowe.[20] RTI was renamed Ingres Corporation in the late 1980s. The company ported the code to DEC VAX/VMS, which was the commercial operating system for DEC VAX computers. They also developed a collection of front-end tools for creating and manipulating databases (e.g., reporterwriters, forms entry and update, etc.) and application development tools. Over time, much of the source was rewritten to add functionality (for example, multiple-statement transactions, SQL, B-tree access method, date/time datatypes, etc.) and improve performance (for example, compiled queries, multithreaded server).
Project Jewel was an early prototype of abstract data types. Ingres was the first database to be certified as a "Rainbow Book" B2 certified database, as such it was adopted by the US National Laboratories (Los Alamos, Livermore, Sandia) for storage for the design of nuclear weapons. It was also deployed by the CIA. Support needs for highly classified air gapped systems led to the creation of an Expert System for problem resolution hosted on the DARPA network.
After DEC withdrew from a planned investment in Ingres,[21] the company was purchased by ASK Corporation in November 1990. The founders left the company over the next several months.
Computer Associates
[edit]This article needs additional citations for verification. (January 2024) |
In 1994, ASK/Ingres was purchased by Computer Associates.[22][23]
In February 2000, Computer Associates announced the general availability of Ingres II 2.0 for Linux. Besides the components found in the SDK, the full edition contains more modules, such as:
- Net: this component makes possible for Ingres utilities and user applications to access databases residing on different installations.
- Replicator: support for replication functions.
- Star: for handling distributed databases.
- Enterprise Access: communication with different database management systems and other, non-relational data sources (used to be called Gateways).
- Protocol Bridge: for communicating with clients on different types of networks.
- Spatial Object Library: for handling two-dimensional spatial objects.
Ingres versions 6.4 and Ingres II have long been a commonly used database management system (DBMS), mainly in data center operations at universities and other public bodies. For a while, it was still able to resist Oracle's dominance due to low licensing costs.
In addition to the low license fees, Ingres II had the advantage of lower resource requirements over Oracle, for example, which is why it could also be used on smaller machines. Disadvantages were the more difficult usability, the lower number of platforms on which this system ran and fewer Ingres-capable applications.
On the grounds that the performance of Ingres was comparable to that of other large DBMSes, Computer Associates raised the license fees sharply, thereby losing a key advantage over Oracle. Insufficient marketing by Computer Associates and the resulting lack of sales as well as a lack of IT technicians who master this system and who could be called on when necessary were partly responsible for a decline in marketshare. As a result, Ingres installations were increasingly replaced by Oracle implementations (only about 15,000 installations worldwide in 2004).
In 2004, Computer Associates (CA) released Ingres R3 under CA Trusted Open Source License (CATOSL), an open source license. The code includes the DBMS server and utilities and the character-based front-end and application-development tools. In essence, it shipped everything except OpenROAD, the Windows 4GL GUI-based development environment.
Ingres Corporation
[edit]In November 2005, Garnett & Helfrich Capital, in partnership with Computer Associates, created a new company called Ingres Corporation, which provided support and services for Ingres, OpenROAD, and the connectivity products.
In February 2006, Ingres Corporation released Ingres 2006 under the GNU General Public Licence. Ingres 9.3 was released on October 7, 2009.[24] It was a limited release targeted at new application development on Linux and Windows only.[25]
The company focused on the open-source community, with the following initiatives:
- Community Bundles – Alliances with other open-source providers and projects, such as Alfresco, JasperSoft, Hibernate, Apache Tomcat, and Eclipse, enable Ingres to provide its platform and technology with other open-source technologies.
- Ingres Icebreaker BI: in 2007, Ingres Corporation partnered with Jaspersoft and rPath start-up to release this business intelligence software based appliance.[26] It consisted of the Ingres 2006 database with rPath Linux and business intelligence tools from JasperSoft.[27] Although it included no hardware, Ingres called it an appliance because all the components of the software stack were tightly integrated and the company supported all the software itself.[28]
- Ingres CAFÉ (Consolidated Application Foundation for Eclipse), created by a team of developers at Carleton University, is an integrated environment that helps software architects accelerate and simplify Java application development.[29]
- Ingres Geospatial was community-based project to create industry-standards-compliant geospatial storage features in the Ingres DBMS. In other words, for storing map data and providing powerful analysis functions within the DBMS.[30]
- Established by Ingres and Carleton University, a series of Open Source Boot Camps were held in 2008 to work with other open-source communities and projects to introduce university and college students and staff to the concepts and realities of open source.[31]
- Other involvement includes: Global Ingres University Alliances, Ingres Engineering Summit, Ingres Janitors Project and several memberships in open-source initiatives.
Ingres 10 was released on October 12, 2010, as a full release, supporting upgrade from earlier versions of the product.[32] It was available on 32-bit and 64-bit Linux, and 32-bit Microsoft Windows.[33]
In November 2010 Garnett & Helfrich Capital acquired the last 20% of equity in Ingres Corp that it did not already own.[34]
Actian
[edit]On September 22, 2011, Ingres Corporation became Actian Corporation, focusing on data management and integration technologies, including Vectorwise/Vector, Btrieve/Pervasive PSQL/Zen, OpenROAD and the Ingres database.
Actian was acquired by HCL Technologies and Sumeru Equity Partners for $330 million.[35] In 2021, HCL Technologies became the sole owner of Actian, which became the Data and Analytics division of HCLSoftware.
On 18 April 2017, Actian X was announced as the first natively integrated hybrid database, designed to manage transactional, analytic and hybrid data workloads from a single database.[36]
Actian X combines the features and capabilities of Ingres and Vector, including column-based storage, vector processing, multi-core parallelism (and more):[37]
- DataConnect 11 for Actian X: DataConnect is an end-to-end application integration solution for designing and deploying data integration with Ingres applications. The bundle included a GUI and development engine, for designing and testing integrations, and a production engine for deployment.
- Enterprise Monitoring Appliance (EMA): helps maintain the health of databases and host systems by monitoring and setting alerts for key system functions like disk usage, I/O performance, transaction log files and network latency. EMA provides early warnings and alerts so problems and potential problems can be quickly resolved.
- Cloud Backup Service: a scalable, secure managed service for storing and managing Ingres backups. More than file or system backup, the service is designed with tight Ingres integration. Backup agents monitor Ingres for checkpoints and journals, and transfer them to cloud storage automatically ensuring consistent backups and successful restores.
- Geospatial: Several geospatial enhancements, highlighted by the ArcGIS plug-in for ESRI, which enables ArcGIS desktop tools to visualize and manipulate Ingres geospatial data. Added 3D support for R-Tree indexes and in-line geospatial functions improves query performance and greatly simplifies coding for geospatial features.
- New features and enhancements: MERGE support, a reuse heuristic for query optimization, compression of network communications, automatic log file rotation, blob encryption, etc.
In 2024, Actian decided to withdraw the Actian X brand, making all its features and capabilities available to Ingres 12.0.
Version history
[edit]- Berkeley-Ingres ("University" Ingres, currently 8.9,[38] public domain)
- RTI Ingres 5.x
- RTI Ingres 6.1 to 6.4
- CA OpenIngres 1.0 to 2.0
- CA Ingres II 2.0 to 2.5
- CA Advantage Ingres 2.6
- CA Ingres R3 (3.0) (under the CA Trusted Open Source License)
- Ingres 2006 (under version 2 of the GPL )
- Ingres 2006 Release 2
- Ingres Database 9.2
- Ingres Database 9.3
- Ingres Database 10
- Actian Ingres 10S (10.1)
- Actian Ingres 10.2
- Actian Ingres 11.0
- Actian Ingres 11.2 [39]
- Actian X 11.0 to 11.2 [40]
- Actian Ingres 12.0 [41]
Ingres release history
[edit]| Release | General availability | End of Enterprise Support | End of Extended Support | End of Obsolescence Support | Notes |
|---|---|---|---|---|---|
| Ingres 6.4 | September, 1991 | 30-Sep-01 | — | 31-Dec-08 | |
| OpenIngres 1.x & 2.x | January, 1996 | September 31, 2000 | — | 31-Dec-08 | It integrated an unstructured data type (audio, video, blob), temporary tables (in memory) and the Visual DBA administration suite |
| Ingres II 2.0 | February, 1999 | 1-May-05 | 31-Dec-08 | 31-Dec-13 | Line locking, variable page size, massive loading, server level replication (the old system of capturing data modifications by rules has been abandoned). |
| Ingres II 2.5 | July, 2001 | 31-Dec-07 | 31-Dec-12 | 31-Dec-17 | First Ingres version for Linux. This version also made it possible to fully exploit 64-bit architectures. Introduction of the JDBC driver. |
| Ingres II 2.6 | May, 2002 | 31-Dec-09 | 31-Dec-14 | 31-Dec-19 | First enterprise-class DBMS to fully exploit the 64-bit architecture under Linux. Support for XML, Unicode and improvement and splitting of administration tools (Ingres Visual Manager, Ingres Performance Monitor, Ingres Import Assistant, Ingres Visual SQL, etc.). |
| Ingres R3 | November, 2004 | 31-Dec-07 | — | — | Computer Associates makes Ingres R3 open source under the CATOSL license. Support for partitioned tables, parallel query and a new data optimization algorithm. |
| Ingres 2006 (9.0 & 9.1) | March, 2007 | 31-Dec-11 | 31-Dec-16 | 31-Dec-21 | Entry of Ingres into the world of open source products (under GPL license). Stability, further enhanced functionality and performance, ease of installation. Release of IceBreaker BI. |
| Ingres 9.2 | November, 2008 | 31-Dec-15 | 31-Dec-20 | 31-Dec-25 | Improved support for JDBC, .Net and PHP in terms of performance. Log shipping features and UTF-8 support. |
| Ingres 10.0 | September, 2010 | 31-Dec-16 | 31-Dec-21 | 31-Dec-26 | The release contains a number of major enhancements that minimize application development time when migrating applications from other databases to Ingres. New features include support for multiversion concurrency control (MVCC), high-performing batched statement execution, full scalar subquery support, support for identifiers up to 256 characters long, and column-level data encryption. The release supports an automated, seamless migration from earlier versions of Ingres. |
| Ingres 10S (10.1) | May, 2012 | 31-May-17 | 31-May-22 | 31-May-27 | Includes comprehensive spatial support, allowing to extend location-based data through spatial-aware applications, avoiding complex add-ons and integrations with other databases, and no need to pay extra to access geospatial features. |
| Ingres 10S (10.1) - VMS Itanium Only | April, 2014 | 31-May-18 | 31-May-23 | 31-May-28 | |
| Ingres 10.2 | 4-Sep-14 | 1-Sep-19 | 1-Sep-22 | 1-Sep-25 | New features include 2-D, 3-D and 4-D Spatial Data Types, Remote GCA, UTF-8 Transliteration, DBMS Level Authentication, IPV4 and IPV6 Data Types and Functions and Per-query Parallelism Level. Users can also take their first steps into Big Data Analytics by applying the new Windowing functions to their existing transactional data. |
| Ingres 11.0 (Solaris SPARC, Solaris AMD, AIX and 32-bit Windows) | 31-Mar-17 | 31-May-23 | 31-May-27 | 31-May-32 | Ingres 11 includes two significant additions for application integration and monitoring. IngresConnect provides an end-to-end solution for designing, deploying and managing data integration, and the Actian Enterprise Monitoring Appliance (EMA) can use Nagios compatible plug-ins now in Ingres to monitor Ingres environments.
Ingres 11 also contains many new geospatial, performance, ease-of-use and security features. A few of the highlights are: ArcGIS plug-in, query optimizer reuse heuristics, automatic log file rotation, IANA timezones, Y2K38 fix, blob encryption and AES password encryption. |
| Ingres 11.0 (VMS Itanium and HP Itanium) | 31-Mar-17 | 31-May-23 | 31-May-27 | (None offered, platform not supported by HPE after Dec 2028) | |
| Ingres 11.2 (VMS Itanium and HP Itanium) | 6-May-22 | 31-Dec-25 | (None offered, platform not supported by HPE after Dec 2028) | (None offered, platform not supported by HPE after Dec 2028) | |
| Ingres 11.2 (Solaris SPARC, Solaris AMD, and AIX) | 6-May-22 | 31-May-27 | 31-May-32 | 31-May-37 | Ingres 11.2 contains many new management, development and security features. Ingres 11.2 introduces Workload Management Phase 1, JSON Support, Data Masking for sensitive data, Partition Management, Pivot Tables, and Encryption Initialization Vectors, among other changes.
Ingres 11.2 also contains a development release of SQL UDFs with development-only support. |
| Ingres 12.0 (Linux, Windows) | 31-May-24 | 31-May-29 | 31-May-34 | 31-May-39 | For Ingres 12.0, Actian decided to withdraw the Actian X brand from the market, with the new release of Ingres inheriting its capabilities and the X100 engine. Other improvements include:
Check the New Features section, on the official documentation,[42] for a complete list. |
| Ingres 12.0 (Solaris SPARC, Solaris AMD and AIX) | 31-May-24 | 31-May-29 | 31-May-34 | 31-May-39 | Ingres 12.0 introduced High Availability option with a Solaris Sparc cluster |
| Ingres 12.0 (VMS x86) | 20-Sep-24 | 20-Sep-29 | 20-Sep-34 | 20-Sep-39 |
With the announcement of Ingres 9.1 (Ingres 2006 release 2) on the VMS platform the support dates for VMS will now follow the normal Actian release dates as listed above with the following exceptions; dropping of the Alpha VMS 2.0 release has been announced and Enterprise Support ended on December 31, 2009 with Extended Support offered through December 31, 2013. All support for VAX VMS ended on December 31, 2008.[43]
Features
[edit]Major features as available in Actian Ingres 11.2:
- A broad subset of ANSI/ISO SQL-92, as well as extensions;
- Cross-platform support;
- ACID compliance;
- Stored procedures in both SQL and QUEL;
- Triggers;
- Cursors;
- Updatable views;
- Primary and secondary indexes;
- Foreign Keys, as well as constraints and indexes on them;
- Partitioned tables with pruning of partitions in optimizer;
- Query caching;
- Sub-SELECTs (i.e. nested SELECTs);
- Embedded SQL, statements that can be embedded in a host language such as C;
- Unicode support;
- Information schema through iidbdb catalog, the instance's "master database" catalog, which holds information on other databases in the instance, database locations, users, permits, etc. Each database within the instance will also hold data such as table column info in its system catalogs. There are numerous ways to access this data, for example via SQL or via a GUI interface such as Actian Director or Visual DBA (VDBA). Other command line utilities such as vwinfo and infodb will also give database and/or table column data;[44]
- Workload management, a set of SQL Mode options to control runtime behavior;
- Database replication support through Ingres Replicator, which can also be used with Enterprise Access products, enabling to replicate data to other databases: Oracle, MS SQL, IBM DB2, RMS, Oracle Rdb, DATACOM/DB, and IBM IMS;
Architecture
[edit]Ingres is a single-node relational database management system, and therefore it is "Share-Everything".
Storage architecture
[edit]Ingres is a disk-oriented DBMS, and by default employ the n-ary storage model (NSM),[45] also known as a row-store.
However, Actian has incorporated columnar storage into its latest version of Ingres (Actian X) to improve its performance on OLAP tasks. Actian X has two storage engines, the traditional Ingres and X100, the same engine from Actian Vector.
Although it is currently branded as the "Actian X Hybrid Database", the term "Hybrid" refers to its capability of performing both OLTP and OLAP tasks by employing a hybrid storage model (i.e. both row and column), not that it has a hybrid storage architecture.[46]
Regarding the storage organization, Ingres supports Heap, Hash, ISAM and B-tree.[47]
Indexes
[edit]Ingres chooses ISAM (Index Sequential Access Method) as the index data structure by default, but also offers B+ Tree, Hash Table, and R-Tree as options. On Actian X, there is also two other options available only for X100 tables:[48]
- X100_IX: Default, creates a primary (clustered) index. Only one primary index per table is allowed.
- X100_SI: Creates a secondary index on additional columns in an X100 table. Can also be specified as VWSI. Secondary indexes are not supported for partitioned tables.
Concurrency control
[edit]Ingres uses multiversion concurrency control (MVCC), deterministic concurrency control, and two-phase locking (deadlock detection).[49]
Isolation levels
[edit]Ingres supports four isolation levels, from favoring consistency to maximizing concurrency: Serializable, Repeatable Read, Read Committed. and Read Uncommitted, Serializable is the default isolation level and it provides the strongest consistency guarantee.[50]
Joins
[edit]Ingres supports joins with hash join, sort-merge join, and nested loop join algorithms. The query optimizer determines which type of join algorithm to use based on its analysis of the query. Nested-loop joins are most often seen on disjoint queries, where correlation variables and table names are arbitrarily used in random order. When there are no restrictions on either table in the join clause, and the rows being joined are spatially continuous, then the query optimizer is likely to choose sort-merge join or hash join.[51]
Installation
[edit]Ingres can be installed as a client (Client Installation) or as a server (Server Installation), the client does not have a database associated with it, but it allows you to access the database created in the server installation.
A typical site installs the Ingres client for workers on the computers that will interact with the Ingres server at the core of the site.
Note that the expression "instance" is synonymous with "installation".
An installation can be thought of as a collection of server processes, shared memory, and semaphores for inter-process communication, as well as disk files used for transaction processing and recovery in the event of a host or installation failure.
Install ID
[edit]An installation is often named by its installation ID. This identifier consists of two case-sensitive characters, starting with a letter. The default is II. The installation ID is used to calculate which ports the Ingres servers will listen on. For example, "II" indicates that the servers are listening on port 21064 and 7 ports after it.
Any host (machine or virtual machine) can have multiple installations of Ingres, but each installation must have a unique identifier to ensure that clients and components interact with the correct installation.
One installation can use multiple installation IDs. A classic example is when you need to run more than 8 processes on the server. Also, while Ingres database servers (iidbms) and Ingres communication servers (iigcc) conventionally use the same installation ID, there is no requirement to do so.
Installation paths
[edit]Some important paths must be assigned at the location where the installation was created. The paths will not change without reinstallation, so you should take care to choose them.
The paths are shown in the following table. Note that the "II_" prefix does not indicate that these paths are for the "II" installation. Each installation, regardless of its ID, will have its own set of these variables.
| Name | Purpose |
|---|---|
| II_SYSTEM | Setup binary files, utilities, text files used for configuration, etc. |
| II_DATABASE | Location of installation master data. |
| II_CHECKPOINT | Database backup location. |
| II_JOURNAL | Location where database installation transactions are logged. The logs use the recovery system to provide point-of-failure recovery. Can be used for audit purposes. |
| II_DUMP | Location where "dump" installation files are stored. They can be generated during "online" database backups and [ what? ] to restore. |
| II_WORK | Used to store work files generated by the server when querying the database. |
Databases
[edit]An Ingres installation (or instance) can support multiple databases, each owned by any user known to the installation. The installation allows multiple databases to be accessed at the same time. The number of databases is a configurable value. Note that this simply limits the number of databases available at any one time and many more databases can be created.
When creating an Ingres server installation, the databases "iidbdb" and "imadb" will be created, owned by the user "$ingres". The iidbdb database, also known as the "Master Catalog database", contains many special tables to manage the installation itself. The imadb (Management Architecture database) database also includes registered objects used to manage the installation.
Of particular note is that databases are not pre-sized. Each database in the installation is allowed to grow in size as much as the free disk space allows.
Data types
[edit]Ingres supports:
- Common data types
- Integers (1 byte, 2 bytes, 4 bytes and 8 bytes)
- Floating-point numbers (4 bytes, 8 bytes)
- Fixed-point numbers
- Character type (fixed and variable length)
- Binary type (fixed and variable length)
- Date and time (ANSI date, time and timestamp)
- Unicode data types
- nchar
- nvarchar
- Types for large objects
- long varchar
- long byte
- Native types
- ingres date
- money
- Geospatial data types (version 10S and later)
- point, multipoint
- linestring, multilinestring
- polygon, multipolygon
- geometry, geometry collection
Postgres
[edit]The Postgres project was started in the mid 1980s to address limitations of existing database-management implementations of the relational model. Primary among these was their inability to let the user define new domains (or "types") which are combinations of simpler domains (see relational model for an explanation of the term "domain"). The project explored other ideas including the incorporation of write-once media (e.g., optical disks), the use of massive storage (e.g., never delete data), inferencing, and object-oriented data models. The implementation also experimented with new interfaces between the database and application programs (e.g., "portals", which are sometimes referred to as "fat cursors").[52]
The resulting project, named "Postgres", aimed at introducing the minimum number of features needed to add complete types support. These included the ability to define types, but also the ability to fully describe relationships – which up until this time had been widely used but maintained entirely by the user. In Postgres, the database "understood" relationships, and could retrieve information in related tables in a natural way using rules.
In the 1990s, Stonebraker started a new company to commercialize Postgres, under the name Illustra. The company and technology were later purchased by Informix Corporation.
See also
[edit]References
[edit]- ^ Actian Corporation (2024-07-14). "Ingres 12.0 Guides". actian.com. Retrieved 2023-08-10.
- ^ "Ingres is a feature rich and robust database (RDBMS)". github.com. November 5, 2019.
- ^ a b c University of California, Berkeley Database Group. "Archive Software Projects". University INGRES project. Archived from the original on January 26, 2014. Retrieved 12 July 2013.
- ^ a b J. Woodfill (1979). "INGRES Version 6.2 Reference Manual" (PDF). Archived from the original (PDF) on 2022-07-01. Retrieved 2022-06-02.
The INGRIS reference manual is subdivided into four parts: Quel describes the commands and features which are used inside of INGRES. Unix describes the ...
- ^
"RTI announces VAX, Unix Ingres". ComputerWorld. November 7, 1983. p. 63.
For VAX-lls Running Unix, Relational Technology Offers Updated DBMS BERKELEY, Calif. — Relational Technology, Inc. (RTI) has announced the Ingres VAX ...
- ^ Pranskevichus, Elvis (9 May 2019). "We Can Do Better Than SQL". edgedb.com. EdgeDB Inc. house blog. Retrieved 29 November 2021.
- ^ Chin, Cedric (7 October 2020). "A Short Story About SQL's Biggest Rival". holistics.io. Holistics Software house blog. Retrieved 29 November 2021.
- ^ a b Joe Hellerstein; Anthony Joseph. "DBMS History". Archived from the original on May 27, 2006.
- ^ "Ingres (Stonebraker)". britannica.com.
(In Michael Stonebraker) ...tenure at Berkeley, Postgres (Post INGRES) in 1986.
- ^ a b L.A. Rowe (2012). "History of the Ingres Corporation". IEEE Annals of the History of Computing. 34 (4): 58–70. doi:10.1109/MAHC.2012.51. S2CID 16078334.
University INGRES had three client applications: the terminal monitor, EQUEL C, and GeoQUEL.
- ^ a b "RDBMS Plenary 1: Early Years" (PDF) (Interview). Interviewed by Burton Grad. Computer History Museum. 2007-06-12. pp. 30–31. Retrieved 2025-05-30.
- ^ a b "RDBMS Workshop: Ingres and Sybase" (PDF) (Interview). Interviewed by Doug Jerger. Computer History Museum. 2007-06-13. Retrieved 2025-05-30.
- ^ The Rise of Relational Databases. 1999. doi:10.17226/6323. ISBN 978-0-309-06278-7.
In search of further support, Stonebraker approached the Defense Advanced Research Projects Agency (DARPA)"
- ^ NSF Funding#s, over time= 0205445, 8715235, 0844480, 0848727, 9116860 "NSF Award Search: Award#9116860 - Design of ..."
DEC has provided the researchers funded under this grant with the equipment ...
- ^ The Rise of Relational Databases - Funding a Revolution. 1999. doi:10.17226/6323. ISBN 978-0-309-06278-7.
- ^ "Capt. Horatio T.P. Webb MIS 4372 Database Alternatives".
Youseffi (at Tandem Computers) built a system that evolved into NonStop SQL. The Tandem database system was a re-implementation of the Ingres technology.
- ^ Andrew Mendelsohn (2013). "The Oracle Story: 1984 – 2001". IEEE Annals of the History of Computing. 35 (2): 10–23. doi:10.1109/MAHC.2012.56. S2CID 17907189.
This article traces the development of the Oracle RDBMS through the mainframe, ... innovations that allowed Oracle to compete so successfully in the market
- ^ Morgenthaler, Gary (2005-12-08). "Oral History of Gary Morgenthaler" (PDF) (Interview). Interviewed by Luann Johnson. Computer History Museum. p. 18. Retrieved 2025-05-30.
- ^ Council, National Research; Board, Computer Science Telecommunications; History, Committee on Innovations in Computing Communications: Lessons From (1999). Funding a Revolution: Government Support for Computing Research. ISBN 978-0309062787.
Robert Epstein, the chief programmer at Ingres in the 1970s, went on to co-found Britton-Lee Incorporated and then Sybase.
- ^ "Eugene Wong". EECS at UC Berkeley.
Eugene Wong ... In 1980 he co-founded (with Michael Stonebraker and Lawrence A. Rowe) ... Relational Technology, Inc., later renamed the INGRES Corporation
- ^ Cite error: The named reference
rdbmsfinancing20070612was invoked but never defined (see the help page). - ^ "CA Takeover Leads to Egress At Ingres Corp". Newsday. June 30, 1994. p. 59. Archived from the original on January 21, 2024. Retrieved January 21, 2024 – via Newspapers.com.
- ^ "Technology". Los Angeles Times. June 30, 1994. Archived from the original on January 21, 2024. Retrieved January 21, 2024.
- ^ "Ingres Database 9.3 Takes Aim At Competitors With Easy Migration Path". Press release. Ingres Corporation. October 7, 2009. Archived from the original on October 10, 2009. Retrieved December 5, 2013.
- ^ "ESD - Electronic Software Distribution". esd.ingres.com. Archived from the original on 2009-12-15. Retrieved 2009-11-17.
- ^ Icebreaker BI [https://web.archive.org/web/20100114002247/http://www.ingres.com/products/icebreaker-bi-appliance.php Archived 2010-01-14 at the Wayback Machine
- ^ "Ingres breaks ice with JasperSoft". 2007-08-23. Retrieved 2023-05-13.
- ^ "Ingres launches Icebreaker BI Appliance". 2007-08-22. Retrieved 2023-05-13.
- ^ Ingres CAFÉ
- ^ "Actian - Hybrid Data Management & Integration". Actian.
- ^ "Open Source Boot Camp". Old web site. Archived from the original on April 7, 2008. Retrieved December 5, 2013.
- ^ "Ingres Database 10 Pulls Out All Stops With Further Migration and Performance Enhancements". Press release. Ingres Corporation. October 12, 2010. Archived from the original on November 7, 2010. Retrieved December 5, 2013.
- ^ "Ingres Database". Former download web page. Ingres Corporation. Archived from the original on September 23, 2010. Retrieved December 5, 2013.
- ^ "CA Technologies sells last of Ingres stake". Silicon Valley Business Journal. November 9, 2010. Retrieved December 7, 2013.
- ^ "Announcement under Regulation 30 (LODR)-Updates on Acquisition". bseindia.com. July 18, 2018.
- ^ "Actian Hybrid Data Solutions Power the Digital Enterprise". www.businesswire.com. 2017-04-18.
- ^ "Introducing Actian X – the new Ingres". April 27, 2017. Retrieved April 10, 2023.
- ^ "Index of /Ingres".
- ^ "ESD - Electronic Software Distribution".
- ^ "Actian Communities". communities.actian.com.
- ^ "New Edition of Renowned Database Enhances Cloud Flexibility, Improves Security, and Speeds Analytics by up to 20%". www.actian.com.
- ^ "Actian Ingres 12.0 New Features". docs.actian.com.
- ^ "Actian X and Ingres". communities.actian.org.
- ^ "iidbdb Catalogs". Actian. 2023-03-14. Retrieved 16 June 2023.
- ^ Arulraj, Joy; Pavlo, Andrew; Menon, Prashanth (June 2016). "Bridging the Archipelago between Row-Stores and Column-Stores for Hybrid Workloads" (PDF). db.cs.cmu.edu. Association for Computing Machinery. Retrieved June 16, 2023.
- ^ "Actian X Hybrid Database" (PDF). Actian.
- ^ "BaseChoosing Storage Structures for your Ingres Database". communities.actian.com.
- ^ "Actian X 11.2 Documentation".
- ^ "Database of Databases — Ingres". 27 June 2022.
- ^ "Ingres".
- ^ "Ingres".
- ^ "sp_cursoroption (Transact-SQL)". 28 February 2023.
Since Transact-SQL positioned UPDATE/DELETE statements operate, by default, on the first row in a fat cursor, sp_cursor SETPOSITION should be used to position the cursor before issuing the positioned UPDATE/DELETE statement.
External links
[edit]Ingres (database)
View on GrokipediaHistory
Origins and academic development (1970s)
The development of Ingres began in 1972 at the University of California, Berkeley, under the leadership of Michael Stonebraker as part of the Berkeley Database Research project, inspired by Edgar F. Codd's relational model papers.[5][6] This initiative aimed to create a practical implementation of relational database technology, funded by grants from the National Science Foundation, the Office of Naval Research, and the Army Research Office.[7] The project leveraged emerging Unix operating system capabilities on PDP-11 minicomputers, marking one of the earliest academic efforts to build a full relational database management system (RDBMS) outside IBM's System R.[8] Key contributors included Eugene Wong, who co-led the effort with Stonebraker, along with graduate students such as Jerry Held and Peter Kreps, who joined in 1974.[9] The initial prototype drew conceptual inspiration from System R's relational approach but diverged by emphasizing the relational model through the QUEL query language, a procedural, nonprocedural sublanguage designed by Wong for high-level data manipulation.[10] QUEL supported relational algebra operations like retrieval and appending via commands such as RETRIEVE and APPEND, embedded within C programs using tools like YACC for parsing.[10] The first public release occurred in 1974, named INGRES (Interactive Graphics and Retrieval System), though the graphics component remained minimal and was largely a misnomer for the database-focused prototype.[11] By 1975, a functional version was operational, with widespread academic distribution reaching 50-60 installations by 1977.[7] Ingres pioneered several innovations in relational database implementation during its academic phase. It introduced multiuser support through a modular process structure on Unix, utilizing four interconnected processes with pipes for communication and physical domain locks to manage concurrency and recovery.[10] Relational algebra was realized via procedural C code, enabling data independence and a relational view of decomposed storage relations, where data was stored in normalized tables to facilitate efficient access.[9] An early decomposition storage model broke complex queries into simpler one-variable subqueries using techniques like tuple substitution, avoiding the need for full join operations in initial implementations.[10] The project overcame significant challenges inherent to 1970s computing constraints. Handling complex queries relied on rudimentary optimization strategies, as modern query optimizers did not exist; instead, Ingres used decomposition algorithms to process multi-variable requests iteratively, though this incurred overhead from repeated Unix pipe calls and limited 64K address space per process.[10] Modularity was achieved by distributing functionality across separate Unix processes—for instance, one for query parsing and another for access methods—which enhanced maintainability but introduced performance bottlenecks due to inter-process communication.[9] These approaches demonstrated the feasibility of relational databases on affordable hardware, influencing subsequent systems despite partial implementations of features like integrity constraints.[8]Commercialization and early corporate phases (1980s–1990s)
In 1980, Michael Stonebraker and other leaders from the University of California, Berkeley's Ingres project founded Relational Technology Inc. (RTI) with venture capital funding to commercialize the academic prototype as a production-ready relational database management system (RDBMS). The company, based in Alameda, California, aimed to adapt the research-oriented Ingres for enterprise use, targeting minicomputer platforms popular in business environments. By 1981, RTI released the first commercial version of Ingres on Digital Equipment Corporation (DEC) VAX systems running VMS or Unix operating systems, initially supporting the QUEL query language while emphasizing relational storage, query optimization, and application development tools. This marked a pivotal shift from academic experimentation to market-driven software engineering, with RTI investing in software capitalization starting in 1986 to accelerate development under accounting standards like SFAS No. 86.[12][13][14] To address growing industry demand for SQL compatibility amid competition from Oracle and others, RTI introduced an SQL interface in 1984 as a front-end to the core Ingres engine, allowing partial replacement of QUEL without fully abandoning the original query language. This enhancement enabled developers to use standardized SQL for ad-hoc queries and application integration while leveraging Ingres's proprietary optimizations. By 1988, RTI went public with an initial public offering that raised approximately $28 million, funding further enhancements and international expansion; the company reincorporated in Delaware and reported revenues of $46.6 million for fiscal 1987, driven by license and maintenance fees. In March 1988, RTI shipped a major update supporting distributed database capabilities through Ingres/Star, which allowed data access across networked heterogeneous systems as if they were a single database, targeting enterprise needs like manufacturing and finance. Ports to additional platforms, including various Unix variants and VMS, broadened its footprint, with over 668 employees by mid-1988 supporting sales in the US, Canada, Europe, and Australia.[12][13][14] In 1989, RTI rebranded as Ingres Corporation, signaling a mature product identity centered on SQL integration. The 1990s saw the evolution to Ingres/SQL as a full-fledged SQL RDBMS, with Release 6.4 documented for Unix and VMS environments, emphasizing compliance with emerging SQL standards while retaining extensions for performance in large-scale deployments. This version supported advanced features like gateways to non-relational data sources (e.g., dBase III files) and robust application development tools, positioning Ingres for government and financial sectors requiring secure, scalable data management. In October 1990, ASK Computer Systems acquired Ingres Corporation for about $110 million in a stock deal, integrating it into ASK's manufacturing-focused portfolio to enhance ERP-like solutions with relational backend capabilities. The acquisition combined Ingres's $100 million-plus revenues with ASK's hardware expertise, though it faced challenges from declining standalone database demand.[15][16][17] Under ASK/Ingres, development emphasized enterprise features, including distributed querying via Ingres/Star for multi-site operations in sectors like finance and public administration, where it competed directly with Oracle and Sybase by offering cost-effective alternatives on open systems. By 1994, Computer Associates (CA) acquired ASK Group, thereby gaining control of Ingres in a deal valued at around $900 million, shifting focus toward integrating it into CA's broader enterprise software suite. This era solidified Ingres's market impact, with installations in government agencies leveraging its NSF-rooted reliability and financial institutions adopting it for transaction processing, contributing to the RDBMS market's growth to $7 billion by 1994. Despite competitive pressures, Ingres maintained a niche in high-reliability environments, influencing standards through its early SQL adoption and distributed architecture.[18][19][20]Acquisitions, modern ownership, and recent advancements (2000s–2025)
In the early 2000s, Ingres remained under the ownership of Computer Associates (CA), which had acquired it through the 1994 purchase of ASK Group, focusing on its commercialization as a robust relational database for enterprise applications. In November 2005, CA spun off Ingres to form the independent Ingres Corporation, backed by private equity firm Garnett & Helfrich Capital, which took a majority stake while CA retained a minority interest; this move allowed Ingres to pursue open-source strategies and expand its market presence.[18] In 2010, Ingres Corporation acquired VectorWise, a columnar analytics database technology, enhancing its capabilities for high-performance data processing. By September 2011, Ingres Corporation rebranded to Actian Corporation, shifting its focus toward hybrid data management solutions that integrated transactional and analytical workloads.[21] Under Actian, the database evolved significantly, with the 2017 launch of Actian X marking a key advancement as the first natively integrated hybrid platform combining Ingres's row-oriented OLTP strengths with VectorWise's columnar OLAP for unified transactional/analytical processing, enabling real-time insights without data movement.[22] In April 2018, Actian was acquired by HCL Technologies and Sumeru Equity Partners for $330 million, integrating it into HCL's portfolio of software products while maintaining its development trajectory.[23] By December 2021, HCL Technologies became the sole owner after acquiring Sumeru's remaining stake, ensuring continued investment in Ingres as part of HCL's data management offerings with no further major ownership changes through 2025.[24] Recent advancements emphasized modernization and cloud compatibility. The Ingres 11.2 release in 2022 introduced features like dynamic data masking for compliance with privacy regulations, JSON data handling for semi-structured data integration, and initial workload management capabilities to optimize resource allocation across mixed workloads.[25] Building on this, Ingres 12.0, released in June 2024, enhanced cloud deployment with native support for AWS and Azure, delivering up to 20% faster analytics performance through optimized query processing, strengthened encryption for data at rest and in transit, and expanded JSON support for modern application development.[4] From 2023 to 2025, updates focused on refining hybrid transactional/analytical processing for seamless OLTP/OLAP convergence, advanced data masking with role-based policies, and comprehensive workload management to handle diverse enterprise demands efficiently.[26] As of 2025, HCL Actian maintains Ingres as a reliable enterprise database, prioritizing tools like the Ingres NeXt initiative for low-risk migrations of legacy applications to hybrid and cloud environments, preserving existing business logic while enabling scalability and cost savings.[27]Version History
Major release milestones
Ingres 1.0 marked the first commercial release of the database system in 1981, developed by Relational Technology Inc. (RTI) with a primary focus on achieving portability across Unix platforms to enable broader enterprise adoption.[28][12] In 1984, an SQL interface was added as a significant update, establishing SQL compatibility while maintaining backward compatibility with the original QUEL language to support existing applications.[12] The Ingres 2006 release incorporated open-source elements under the California license and expanded platform support to include Windows, facilitating greater accessibility for developers and organizations transitioning from proprietary environments.[29][30] Ingres 10 was released in 2010, with an emphasis on enhanced scalability to handle large datasets in high-volume transactional environments, followed by the acquisition by Actian Corporation in 2011.[31][32] Ingres 11, launched in 2015, transformed the system into a hybrid database by integrating columnar storage alongside traditional row-based structures, optimizing it for both transactional processing and analytical workloads.[33] The most recent major milestone, Ingres 12.0, arrived in 2024 with cloud-native enhancements such as support for Docker containers in Kubernetes environments and improvements enabling up to 20% faster query execution through optimized workload management. As of November 2025, Ingres 12.0 is the current major version.[4]Key feature evolutions across versions
In the early 1980s, Ingres transitioned from its original QUEL query language to SQL compatibility to align with emerging industry standards, with the SQL interface added in 1984 while retaining QUEL as the core engine.[12] This shift enabled broader adoption amid competition from SQL-based systems like Oracle. Concurrently, the commercial release introduced Application By Forms (ABF), a procedural development tool for building forms-based applications without traditional programming languages, enhancing rapid application development for enterprise users.[34] During the 1990s and 2000s, Ingres expanded support for distributed environments, building on its foundational distributed query processing capabilities introduced in the late 1970s to handle queries across networked databases.[35] Replication features evolved through tools like Ingres Replicator, enabling data synchronization for high availability and load balancing in multi-site setups. Connectivity standards were also integrated, with ODBC drivers available from the mid-1990s to facilitate integration with Windows applications, followed by JDBC support in the early 2000s for Java-based ecosystems.[36] Ingres 11, released in 2015, introduced key enhancements for modern data handling, including JSON data type support for semi-structured data storage and querying, data masking for compliance in development environments, improved partition management for large tables, and pivot tables for analytical reporting. These features addressed growing needs for flexibility in mixed workloads. The 2021 release of Ingres 11.2 built on this foundation with Workload Management Phase 1, allowing prioritization and resource allocation for concurrent queries to optimize performance under varying loads. It also added encryption at rest to protect table data, logs, and backups using AES standards, alongside refined backup and restore processes for faster recovery. JSON support was extended to X100 columnar tables, partition management gained automation, and pivot tables improved usability for ad-hoc analysis.[25][37] Ingres 12.0, launched in 2024, focused on performance and deployment efficiency, delivering up to 20% faster analytics through optimizations including vectorized execution in the query engine for columnar data processing. Security was bolstered with enhanced role-based access controls and multi-factor authentication integration. Cloud provisioning was simplified via container support and automated configuration, easing migrations to hybrid environments.[22] Overall, Ingres has evolved from a monolithic relational system to a hybrid OLTP/OLAP platform, incorporating row and columnar storage for transactional and analytical workloads. Open-source contributions since 2005, including the core DBMS and administration tools under GPL, have fostered community-driven enhancements while maintaining enterprise-grade reliability.[38][33]Core Features
Relational database capabilities
Ingres implements the relational model by organizing data into tables, where each table functions as a relation consisting of tuples (rows) and attributes (columns), providing a structured way to represent entities and their properties while ensuring data independence between logical and physical storage. Primary keys are defined on one or more columns to uniquely identify each tuple within a table, preventing duplicates and serving as the foundation for relationships across tables. Foreign keys reference primary keys in other tables, enabling the establishment of links between relations to model real-world associations, such as linking employee records to department records. Referential integrity is enforced through these foreign key constraints, which automatically check that foreign key values match existing primary key values or allow nulls where appropriate, thereby preventing orphaned records and maintaining consistency in the database.[39] Ingres adheres to ACID properties to guarantee reliable transaction processing. Atomicity is achieved by treating each transaction as an indivisible unit, where either all operations succeed or none are applied, using rollback mechanisms to undo partial changes in case of failure. Consistency is preserved through constraint enforcement, including primary and foreign keys, ensuring that database rules are upheld after every transaction. Isolation is supported via multi-version concurrency control (MVCC), which maintains multiple versions of data items to prevent concurrent transactions from interfering with one another without blocking readers or writers.[40] Durability is ensured by logging all committed changes to non-volatile storage, allowing recovery from system failures without data loss. These features make Ingres suitable for mission-critical applications requiring robust data integrity.[41][42] The system supports fundamental relational operations for data manipulation. Insertion adds new tuples to a relation, populating specified attributes with values while respecting constraints like primary key uniqueness. Updates modify attribute values in existing tuples, applying changes selectively based on conditions to avoid unintended alterations. Deletion removes tuples that satisfy given criteria, with referential integrity checks preventing the removal of referenced primary keys unless cascading actions are defined. Retrieval, or selection, fetches tuples based on predicates (selections) and projects specific attributes, allowing users to view subsets of data without altering the underlying relations. These operations form the basis for declarative query processing in Ingres.[10] A distinctive aspect of Ingres is its support for a decomposition storage model, particularly in its columnar storage option, where table attributes are stored in separate files rather than as fixed-length row tuples, optimizing access for attribute-specific queries and analytical workloads by reducing I/O overhead. This contrasts with traditional row-oriented storage and enhances performance for large-scale data processing. For query planning, Ingres employs a cost-based optimizer that evaluates multiple execution strategies using statistics on table sizes, index selectivity, and system resources to select the lowest-cost plan, incorporating rules for transformations like predicate pushdown. Later versions have extended these capabilities with SQL-specific enhancements for broader compatibility.[33][43]SQL compliance and proprietary extensions
Ingres supports the full range of Data Definition Language (DDL) and Data Manipulation Language (DML) statements, enabling comprehensive database schema management and data operations in line with core SQL standards. The system achieves compliance at the Entry Level of ANSI/ISO SQL-92, configurable through specific session parameters to enforce strict adherence to this specification, including rules for identifiers, delimiters, and case sensitivity.[44][45] This foundational compliance ensures portability of basic SQL applications while supporting advanced features from subsequent standards, such as window functions for analytical queries, which compute values over defined row sets using syntax likeOVER (PARTITION BY ... ORDER BY ... ).[46]
Actian, the steward of Ingres, has actively participated in the SQL standards development process for over 25 years, influencing enhancements in areas like data handling and query expressiveness.[47] Ingres incorporates elements from SQL:2011 and beyond, including support for common table expressions (CTEs) and recursive queries via WITH RECURSIVE. Since version 11.2, it provides JSON querying capabilities compliant with the ISO/IEC 9075-16:2016 standard, allowing storage of JSON data in character columns and manipulation through functions like JSON_OBJECT, JSON_ARRAY, and path-based extraction operators (e.g., -> and #>) for building and querying semi-structured data.[48][49]
While SQL has been the primary query language since the late 1980s, Ingres retains optional compatibility with its original QUEL language through the 4GL environment, permitting legacy applications to use QUEL statements alongside SQL for backward compatibility.[50] Proprietary extensions enhance enterprise functionality, including embedded SQL integration within the OpenROAD 4GL for rapid application development, where SQL statements are seamlessly incorporated into object-oriented code for procedural logic and UI building.[51] Additional extensions cover array handling in embedded contexts via indicator arrays for dynamic SQL operations and built-in statistical aggregates like STDDEV and VARIANCE for analytical computations over datasets.[52][53]
To address high-volume data scenarios, Ingres offers proprietary bulk operations such as COPY FROM and COPY INTO PROGRAM, which enable efficient loading of large datasets from files or memory buffers, bypassing row-by-row processing.[54][55] These extensions prioritize enterprise scalability without compromising core SQL interoperability, allowing partial ANSI compliance while accommodating specialized needs like high-throughput transactions and analytics.
System Architecture
Storage and indexing mechanisms
Ingres employs a row-oriented storage model in its traditional implementation, where each table is stored as a single file containing rows in an unstructured manner, supporting variable-length records to accommodate diverse data sizes. Tables can be organized as heaps, which append new rows to data pages without a specific order, with new insertions directed to the last page and space reuse limited to that page until full; this can be configured as the default via thetable_auto_structure parameter set to HEAP. This structure is efficient for bulk loading and read-only scenarios but can lead to fragmentation over time as deletions create gaps in earlier pages.[56][57]
File structures in Ingres include B-tree for maintaining sorted order dynamically, allowing efficient range queries and insertions; hash for direct key-based access via a hashing algorithm that maps keys to fixed buckets, ideal for equality searches; ISAM (Indexed Sequential Access Method) for static, sorted data with pre-allocated pages; and R-tree for spatial indexing to support multi-dimensional range queries. These structures organize data into index pages for navigation, leaf pages for key-row pointers, and data pages for actual row storage, enabling fast retrieval based on primary keys. Variable-length records are handled by packing rows into pages, with overflow to additional pages as needed. B-tree handles duplicates without overflow chains by allowing multiple entries under the same key.[58][59][60]
Indexing mechanisms primarily utilize B-tree, hash, and R-tree structures for both primary and secondary indexes, with composite indexes supporting multi-column queries by combining keys in a single index file. Secondary indexes reference rows via tuple identifiers (TID), providing alternative access paths without duplicating data. While bitmap indexes are not a core feature in standard Ingres, the system supports efficient bitmapped representations internally for certain catalog operations.[1]
Space management features automatic extent allocation, where storage is provisioned in configurable extents (groups of pages) to accommodate growth, reducing manual intervention. Fragmentation occurs through overflow chains in heap, hash, and ISAM structures, where full pages link to additional ones; B-tree minimizes this via balanced growth. For large-scale partitioning, Ingres supports table fragmentation, distributing rows across multiple locations or nodes based on rules like hash or range, enhancing scalability in distributed environments.[61]
Since version 11, Ingres introduces hybrid storage via integration with the X100 engine, enabling columnar storage where columns are stored contiguously in separate data blocks or projections for analytical workloads, improving compression and scan efficiency via techniques like run-length encoding and dictionary encoding. This mode supports row-wise insertion and retrieval for compatibility while leveraging column-wise internals.[62]
Concurrency control and isolation
Ingres employs a hybrid concurrency model that combines multi-version concurrency control (MVCC) with locking to manage concurrent access by multiple transactions, enabling readers to obtain consistent snapshots without blocking writers in many cases.[63][40] This approach integrates a two-phase locking (2PL) protocol, where transactions acquire locks during an expanding phase and release them only after the shrinking phase begins upon commit, ensuring serializable execution while minimizing contention.[64] MVCC works by maintaining multiple versions of data rows, allowing each transaction to see a consistent view based on its start time, which reduces lock overhead for read operations compared to pure locking schemes.[65] The system supports a range of lock modes and granularities to balance concurrency and consistency. Lock types include shared (S) locks for concurrent read access, exclusive (X) locks for modifications that block other writers and upgradable readers, and intention locks such as intent shared (IS) and intent exclusive (IX) to signal potential finer-grained locks on child resources.[66][67] Granularities range from row-level for precise control in high-concurrency scenarios, to page, table, and database levels for broader protection, with MVCC-level locking providing version-based isolation without traditional row locks for readers.[68] For example, a transaction performing updates acquires an IX lock on a table before obtaining X locks on specific pages or rows, preventing conflicts while allowing parallel reads via MVCC snapshots. Ingres adheres to the ANSI/ISO SQL-92 standard for transaction isolation levels, offering four configurable options via theSET SESSION ISOLATION LEVEL statement.[69][70] Read uncommitted (RU) permits dirty reads for maximum concurrency but risks inconsistent data; read committed (RC) ensures only committed changes are visible, avoiding dirty reads at the cost of potential non-repeatable reads; repeatable read (RR) prevents non-repeatable and dirty reads by using MVCC snapshots; and serializable (SR) provides the strictest isolation, equivalent to 2PL serial execution, blocking phantoms through lock escalation if needed.[71] These levels allow administrators to tune performance based on workload, with RR often serving as the default for balanced OLTP applications.
Deadlock detection in Ingres leverages the 2PL framework, constructing wait-for graphs to identify cycles among blocked transactions and incorporating configurable timeouts to abort long-waiting operations.[64] Upon detecting a deadlock, the system selects a victim transaction—typically the one with the least work completed—and rolls it back, releasing its locks to resolve the cycle, while notifying the application with an error code for retry logic.[72] Timeouts prevent indefinite waits, with the default threshold adjustable via session parameters, ensuring recovery without manual intervention in most cases.[73]
Beginning with version 11, Ingres enhanced its concurrency model for hybrid transaction-analytical processing (HTAP) workloads by introducing optimistic concurrency control (OCC) in the X100 analytics engine, which defers conflict checks until commit time to boost throughput on read-intensive queries.[74][75] This OCC approach assumes low contention in analytics scenarios, validating transactions against MVCC versions at the end rather than acquiring locks upfront, thereby reducing overhead and enabling higher parallelism compared to traditional 2PL in the transactional engine.[76]
Query processing including joins
Ingres processes SQL queries through a structured pipeline consisting of parsing, semantic analysis, optimization, and execution. The parser analyzes the input SQL statement for syntactic correctness, converting it into an internal tree representation. A subsequent semantic checker validates the query against the database schema, ensuring references to tables, columns, and privileges are valid. The optimizer then generates an efficient execution plan, followed by the executor, which interprets and runs the plan to retrieve or modify data.[77] The query optimizer in Ingres is primarily rule-based, applying transformation rules to rewrite queries for efficiency, such as flattening nested subqueries into equijoins where beneficial. It incorporates cost estimates, primarily based on I/O operations and selectivity, to evaluate multiple query execution plans (QEPs) and select the lowest-cost alternative. Rewrite rules handle subqueries by decomposing them or integrating them into the main query, reducing intermediate result sizes; for example, correlated subqueries may be optimized via tuple substitution techniques. The optimizer can be tuned via session-level flags, such as enabling exhaustive enumeration for complex joins.[78] Ingres supports several join methods, selected adaptively by the optimizer based on table sizes, statistics, and access paths. Nested-loop joins are favored for small or indexed inner tables, iterating over the outer relation and probing the inner for matches. Hash joins build a hash table on the smaller relation for fast lookups, ideal when join keys have high selectivity and memory is sufficient. Sort-merge joins sort both relations on the join key before merging, performing well for large, unsorted inputs or when data is already ordered via indices. The choice is driven by cost models estimating I/O and CPU, with rules prioritizing hash or sort-merge for equijoins on large tables to avoid quadratic costs of nested loops.[1][79] Statistics are crucial for accurate cost estimates and join selectivity predictions, gathered automatically via theoptimizedb utility or explicitly with CREATE STATISTICS. This process samples table rows (default up to 1 million for large tables, or all rows with NOSAMPLE) to compute cardinalities, densities, and histograms representing data distributions. Histograms, stored in the iihistogram system catalog, use up to 32,000 buckets (default 1,000) to model skewed values, enabling better cardinality estimates for predicates and joins; for instance, column groups for 2-4 correlated fields improve multi-column selectivity. Regular updates ensure optimizer decisions reflect data changes, with sampling percentages tunable for precision versus overhead.[80][81]
Since version 10, Ingres extends query processing with parallel execution in distributed and multi-node setups, decomposing complex queries into parallelizable segments like scans and joins. This leverages multiple CPU cores or nodes for reduced latency on analytical workloads, with the optimizer generating plans that distribute operations while preserving correctness.[82]
Data Types and Schemas
Supported primitive data types
Ingres supports a range of primitive data types for storing basic values in its relational database tables, categorized primarily into numeric, character, date/time, binary, and boolean types. These types are defined at the column level during table creation and adhere to standard SQL conventions with some Ingres-specific implementations for storage efficiency and precision.[83]Numeric Data Types
Numeric types in Ingres handle exact and approximate representations of numbers, essential for arithmetic operations and precise calculations. The INTEGER type stores whole numbers using 4 bytes, supporting a range from -2,147,483,648 to 2,147,483,647, making it suitable for most counting and indexing needs. Other integer types include TINYINT (1 byte, -128 to 127), SMALLINT (2 bytes, -32,768 to 32,767), and BIGINT (8 bytes, -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807).[84] The FLOAT type provides approximate floating-point storage with 8 bytes (as FLOAT or FLOAT8), offering a range of approximately -1.8E+308 to 1.8E+308 and up to 14 digits of precision, ideal for scientific computations where exact decimal representation is not required. A single-precision variant, FLOAT4, uses 4 bytes with a range of -1.0E+38 to 1.0E+38 and about 7 digits of precision. The MONEY type stores currency values in 8 bytes, ranging from -$999,999,999,999.99 to $999,999,999,999.99. For fixed-point precision, the DECIMAL(p,s) type allows user-specified precision (p, up to 39 digits) and scale (s, up to p), with storage varying based on these parameters, ensuring accurate financial or measurement data without rounding errors inherent in floating-point types.[84][85]Character Data Types
Character types manage textual data, supporting both fixed and variable lengths for efficient storage of strings. The CHAR(n) type allocates a fixed n bytes (padded with spaces if needed), where n ranges from 1 to 32,000 characters, though practical limits depend on row size constraints. VARCHAR(n) stores variable-length strings up to n bytes (plus 2 bytes for length indicator), with a maximum of 32,000 characters, allowing space savings for shorter values compared to fixed-length alternatives. The TEXT type, now deprecated, is a variable-length string limited to 32,000 bytes. For larger textual content, the LONG VARCHAR type accommodates variable-length strings up to 2 GB, suitable for extensive text data such as documents or logs, while maintaining compatibility with standard VARCHAR operations like substring extraction and pattern matching and requiring special data handlers for operations exceeding standard limits. These types support ASCII and Unicode encodings, with conversions handled automatically during queries.[84][86]Date/Time Data Types
Date and time types facilitate temporal data storage and manipulation, aligning with SQL standards for chronological operations. The DATE type (ANSIDATE) uses 4 bytes to represent calendar dates from January 1, 0001, to December 31, 9999, stored as an integer offset from a base date for efficient comparisons. An alternative INGRESDATE uses 12 bytes with flexible formats. TIME occupies 10 bytes for times from 00:00:00 to 23:59:59, with precision up to 9 fractional seconds. TIMESTAMP combines date and time in 14 bytes, supporting up to 9 fractional digits of precision (default 6, microsecond level) for the full range from 0001-01-01 00:00:00.000000000 to 9999-12-31 23:59:59.999999999, enabling high-resolution event logging. The INTERVAL type stores durations between two points, such as days or months, with storage varying by qualifiers (e.g., 3 bytes for YEAR TO MONTH, 12 bytes for DAY TO SECOND) and precision up to 9 digits, useful for arithmetic like date additions.[84][87]Binary Data Types
Binary types store opaque byte sequences without character interpretation, commonly used for images or raw data. The BYTE type (synonymous with BINARY(n)) reserves a fixed n bytes (padded with zeros), supporting lengths from 1 to 32,000 bytes for consistent storage of fixed-size blobs. VARBYTE (or VARBINARY(n)) handles variable lengths up to 32,000 bytes plus 2 bytes for the length, avoiding padding and optimizing space for irregular binary inputs like serialized objects. For larger binary content, the LONG BYTE type supports up to 2 GB.[84][88]Boolean Data Type
The BOOLEAN type uses 1 byte to represent logical values: TRUE (1), FALSE (0), or NULL (unknown), providing a compact way to store flags or conditions in tables. NULL handling follows standard SQL semantics, where unassigned values default to NULL and propagate in operations unless explicitly managed with IS NULL checks. These primitive types form the foundation for defining table schemas, enabling flexible data modeling while integrating seamlessly with Ingres's query engine.[84]Advanced types, constraints, and schema management
Ingres supports several advanced data types beyond primitive ones, enabling the storage of complex and large-scale data structures. The LONG VARCHAR type accommodates variable-length character strings up to 2 GB, suitable for extensive text data such as documents or logs, while maintaining compatibility with standard VARCHAR operations like substring extraction and pattern matching. Similarly, the LONG BYTE type handles binary large objects (BLOBs) up to 2 GB, ideal for storing unstructured data like images or serialized files, with support for bulk loading and retrieval via specialized handlers in embedded SQL applications. These types address limitations of fixed-size primitives by allowing seamless integration into tables without predefined length caps beyond the maximum.[84][89][90] Introduced in Ingres version 11.0, Ingres provides support for JSON data adhering to the ISO 9075-16 standard. JSON values are stored in character columns such as CHAR, VARCHAR, or LONG VARCHAR, without a dedicated data type. This support includes functions for querying and manipulation of nested objects and arrays, such as validation, extraction (e.g., JSON_VALUE), and construction (e.g., JSON_OBJECT), facilitating integration with modern web and NoSQL workflows. JSON arrays, as comma-separated lists of heterogeneous values enclosed in brackets, enable multi-dimensional representations without requiring separate normalization, though they are treated as atomic values in relational operations.[83][91] In Ingres 12.0, additional primitive types include UUID for 128-bit unique identifiers (stored in 16 bytes? wait, docs say 128-bit), IPv4 (4 bytes, IP addresses), and IPv6 (16 bytes).[84] Spatial data types, available as built-in extensions from Ingres version 10S onward, include point, linestring, polygon, and multipoint geometries in two-dimensional (2D), three-dimensional (3D), and four-dimensional (4D) variants. These types track relative positions using coordinate systems like WKT (Well-Known Text) or WKB (Well-Known Binary) formats, supporting geospatial queries such as distance calculations and spatial joins via the Geospatial User module. User-defined binary data can be managed through custom extensions or the LONG BYTE type, allowing opaque handling of proprietary formats without exposing internal structure to the query engine.[92] Integrity constraints in Ingres enforce data quality at the table level during insert, update, and delete operations, with validation occurring at statement completion to ensure atomicity. The NOT NULL constraint prevents null values in specified columns, essential for mandatory fields like primary keys. UNIQUE constraints guarantee distinct values across a single column or composite set, automatically creating supporting indexes and allowing up to 32 columns per constraint; violations trigger errors without affecting committed data. CHECK constraints apply Boolean expressions to restrict column values (e.g.,CHECK (salary > 0)), supporting complex conditions involving multiple columns while deferring evaluation until transaction commit if specified.[39][93]
Schema management in Ingres relies on standard SQL DDL statements for defining and modifying structures. The CREATE TABLE statement defines tables with columns, constraints, and storage options, while CREATE VIEW constructs virtual tables from queries for simplified access or security masking. ALTER TABLE enables modifications such as adding/dropping columns, renaming tables, or adjusting constraints post-creation, preserving existing data and indexes where possible. Access control uses GRANT to assign privileges like SELECT, INSERT, UPDATE, DELETE, and REFERENCES on tables or views to users, groups, or roles, with the GRANT OPTION allowing further delegation; REVOKE withdraws these privileges, cascading to dependents if specified, to maintain fine-grained security without altering schema definitions.[94][95]
Installation and Configuration
Initial setup and installation options
Ingres supports installation on a range of platforms, including Linux (such as Red Hat Enterprise Linux 8 and 9), Windows, and various Unix variants like IBM AIX, HP-UX, Solaris, and OpenVMS.[96][97][98] Beginning with version 12.0, containerized deployments are available via Docker, enabling easier portability and orchestration in modern environments.[99][100] Installation methods depend on the operating system. For Linux distributions, Ingres is distributed as RPM packages, which can be installed using theinstall.sh script for an interactive or automated process, or directly via RPM commands for command-line efficiency.[101][102] On Windows, the primary method involves running the graphical setup.exe installer from the distribution root, which guides users through component selection and configuration.[103] Both platforms support silent (unattended) installations, using response files generated from prior runs or predefined parameters, ideal for scripted deployments in enterprise settings.[104][105] For containerized setups, Docker images are provided through Actian's electronic software distribution, with installation following standard Docker pull and run procedures.[99]
Prior to installation, verify that the target system meets hardware and software requirements outlined in the platform-specific Readme file, including sufficient RAM and disk space.[106] On Linux, adjust kernel parameters to support shared memory allocation, such as ensuring a minimum 100 MB shared memory segment via settings like shmmax and shmmni in /etc/sysctl.conf, to accommodate Ingres' buffering needs.[107] Additionally, create a dedicated installation owner account, typically the ingres user belonging to the ingres group, to manage permissions and ownership of Ingres files and processes; installations must be performed as this user.[108] For specialized components like the X100 engine, further tweaks such as increasing the vm.max_map_count kernel parameter may be required to prevent memory mapping limits.[109]
The primary configuration file, config.dat located in the Ingres installation directory (typically $II_SYSTEM/ingres/files), stores key parameters affecting system behavior.[110] Notable among these is the default page size, controlled by the *.dbms.*.default_page_size parameter, which is set to 4096 bytes (4 KB) in Ingres 12.0 to optimize storage and I/O performance across supported page size options (2 KB, 4 KB, 8 KB, 16 KB, 32 KB, or 64 KB).[110][111] Other parameters in config.dat, such as those for buffer caching and decimal handling rules, can be edited post-installation but require an Ingres restart to take effect.[112]
Following installation, verify the setup by executing the ingstart script as the ingres user to initialize the Ingres instance, which launches essential processes like the Name Server, Database Manager, and logging system; monitor output for successful startup messages and check process status with tools like ps or ingstatus.[29][113] To confirm operational integrity, perform a clean shutdown using ingstop, ensuring all processes terminate without errors, and optionally test connectivity with a simple SQL session via the sql tool.[29][114]
Database creation, paths, and identifiers
In Actian Ingres, databases are created using thecreatedb command-line utility, which initializes a new database instance and designates the issuing user as its database administrator (DBA).[115] The basic syntax is createdb [options] dbname, where dbname specifies the database name, and options allow customization such as the -L location parameter to define the primary storage path for data files (e.g., createdb -L /path/to/data mydb directs files to a custom directory, overriding the default ii_database location set during installation).[115] Additionally, the -l collation parameter sets the collation sequence for sorting and comparison (e.g., createdb -l caseless mydb for case-insensitive operations), defaulting to the environment variable II_COLLATION if unspecified; for Unicode-enabled databases (default since Ingres 10), normalization forms like NFC can be applied via the -i flag combined with collation options.[115][116] Upon execution, createdb automatically generates subdirectories under specified or default locations for work files, journals, dumps, and checkpoints, ensuring the database is ready for use while integrating it into the master iidbdb catalog for installation-wide tracking.[117]
The II_SYSTEM environment variable defines the root path for Ingres binaries and system files, with a default of /opt/[Actian](/page/Actian)/IngresII on Linux installations, housing executables, libraries, and configuration files essential for database operations.[118] Data files for user databases reside in paths governed by the ii_database location (defaulting to a subdirectory under II_SYSTEM/ingres/[data](/page/Data)), which can be overridden per database during creation to support distributed storage; this separation allows scalability across disks or filesystems.[119] For multi-instance setups on the same host, a unique two-character instance ID (default II) is assigned during installation, prepending identifiers like iidbdb (the master database) to prevent resource conflicts—e.g., II yields iidbdb as the catalog storing metadata on all databases, users, and locations across the instance.[120][121]
Database management involves commands like destroydb for removal, which deletes the specified database, its directory, and all associated files (e.g., destroydb mydb), but requires the database to be closed and the user to hold DBA privileges or security access; it cannot target the master iidbdb.[122] To maintain consistency, the ckpdb command performs checkpointing, creating a recoverable snapshot by flushing modified pages to disk and updating the database configuration file (e.g., ckpdb mydb checkpoints the entire database, while ckpdb mydb table1 table2 limits to specific tables), enabling rollforward recovery from failures without downtime in online mode.[123]
Best practices recommend configuring each database with dedicated paths for logs, journals, and dumps to optimize performance and recovery—e.g., using distinct locations like ii_journal for transaction journals (tracking changes for rollback), ii_dump for before-images (used in rollforward), and ii_checkpoint for snapshots—avoiding shared disks with the transaction log to facilitate offline recovery and prevent I/O bottlenecks.[124][125] These separations, specified via environment variables or createdb options, enhance fault tolerance by allowing independent management of growth in journal and dump files, which accumulate with transaction volume.[126]
