ElevateDB 2.26 is now available for download. If you're an existing customer, then you should be receiving an email shortly with download instructions.

The complete list of breaking changes and new features is below.

2.26 Breaking Changes

---

The following are breaking changes in 2.26:

• The following incident report:
  
  Incident Report #4528 - Altering a Table Results in an Incorrect Table Structure Checksum
  
  deals with an issue with incorrect checksum calculations during table alterations. This bug can affect your ability to restore backups when restoring only table files without also restoring the database catalog. However, please keep in mind that the table structure checksums are only re-computed when a table is altered in some way, and under normal operation are simply just stored and compared to ensure that the physical table files match the table structure for the table in the database catalog.



• There is a new JOININDEXTHRESHHOLD keyword available for the SQL SELECT statement. This keyword controls how ElevateDB handles optimized (indexed) WHERE conditions on tables that are the target of INNER JOINs. For more general information, please see the How ElevateDB Selects the Rows section in the Optimizer topic in the SQL manual.
  
  Previously, ElevateDB would simply use any available, usable index and build a bitmap that represented the set of rows, irrespective of how many rows were selected. This works fine when there are no joins, but can be problematic when the number of rows selected is large and the table is also the target of an INNER JOIN. In such cases, the INNER JOIN condition's bitmap must constantly be assigned/ANDed with the WHERE condition's bitmap and, because the join condition's bitmap typically represents a much smaller set of rows than the WHERE condition, this process of reconciling the bitmaps becomes computationally expensive and a drag on performance.
  
  The value provided with JOININDEXTHRESHHOLD clause is an integer value representing a percentage of rows that, when exceeded, causes ElevateDB to treat such WHERE conditions as un-optimized row scans instead of index scans. This eliminates the computationally expensive bitmap operations and drastically improves the performance of the SELECT statement. The default value for the JOININDEXTHRESHHOLD is 75. This means that a WHERE condition must select at least 75% of the rows in a table is also the target of an INNER JOIN condition in order to be converted into a row scan.

2.26 New Features

---

The following are the new features in 2.26:

• There is a new NO BACKUP FILES clause included with the ALTER TABLE, CREATE INDEX, CREATE TEXT INDEX, ALTER INDEX, ALTER TEXT INDEX, DROP INDEX, and OPTIMIZE TABLE SQL statements. This clause allows you to stop ElevateDB from retaining backup files (*.old) for physical table files after the execution of the SQL statement completes.
  
  
   The NO BACKUP FILES clause does not apply to physical backup files created for the database catalog, which are always created and retained. Also, if the application executing the SQL statement is killed for any reason, it is still possible for these backup files to be present and not removed.



• There is a new FROM PUBLISHED UPDATES clause included with the CREATE TABLE statement. This clause allows you to create a table (permanent or temporary) that includes all pending published updates for all, or some, of the tables in the database.



• Query execution can now be cancelled while ElevateDB is executing un-optimized WHERE conditions on tables. Previously, ElevateDB would need to wait until such conditions were executed before it could cancel the query execution, and could only cancel query execution while executing joins and building the result set. This design was used for performance reasons, but it resulted in situations where runaway un-optimized queries could never be killed without killing the application itself.

In addition, this release contains several bug fixes, which are detailed here.

---

Tags: ElevateDB, New Releases

Permanent Link

Comments (0)	You must be logged in to comment