VistaDB 5
Gibraltar VistaDB > What's New - Version 5.5 > Getting Started - What's New - Version 5.1
Getting Started - What's New - Version 5.1
Review Upgrade Instructions below for details on compatibility changes in VistaDB 5.1

New Features in This Release

Storage Layer Optimizations

The internal storage engine used for deserializing and serializing rows for data tables and indexes has been revised to eliminate the need to process rows in the same page that aren't used.  The net effect is a doubling in performance of single-row writes and inserts and up to a seven fold improvement in index lookup performance.  For more details see VistaDB 5.1 Dramatically Speeds Up, Well, Everything on our blog

Query Optimizer Improvements

The query optimizer in VistaDB 4 could only apply the first column of each index in optimizing a query.  The query optimizer in 5.0 could apply a multi-column index and be far more efficient when applicable constraints are ANDed together but had to choose between that approach or an approach similar to the older single-column optimization and could not be easily predicted by users.  The query optimizer in 5.1 will seek multiple indexes to cover constraints and can use multiple columns from any index for applicable constraints producing both the improved efficiency of multi-column indexes—particularly when JOINing on multi-column keys—and the generality of combining filters from multiple available indexes to cover available constraints.

Query Optimizer Performs Estimation

The query optimizer now estimates the work and effectiveness of applying each constraint and index.  It is able to reduce the work needed to mark a filter for a constraint which would keep more than half of the available rows of a table by estimating when marking the excluded rows would take less time than the included ones.  It can then compute the actual filters for each applied index by priority based on least work and greatest effectiveness (fewest rows included), and it can end further (wasteful) optimization when the next-most-effective filter would take more work than simply checking each row in the already-filtered set.

Query Optimizer Migrates Constraints

SQL allows for constraints (WHERE clauses and Join predicates) to be specified any point after the related tables are defined. This can be a more clear TSQL syntax in some scenarios. VistaDB 5 processes the constraint exactly where it was mentioned even if that was much later in the query than it could be applied. VistaDB 4 would consolidate all JOIN and WHERE constraints into one combined clause which produced incorrect results with some OUTER JOIN scenarios.  Now, VistaDB will apply constraints from any JOIN or WHERE clause to attempt to optimize the table each constraint applies to.

Execution Engine Runs Correlated Sub-queries More Efficiently

In the past, VistaDB has treated each sub-query independently.  Correlated sub-queries had to be re-executed for each row of the parent query even when the differences were only in non-correlated tables not referenced in the sub-query.  While this produced accurate results, the extra work could significantly degrade performance—particularly for some O/RM tools which rely on sub-queries.  VistaDB will now re-execute a correlated sub-query only when a correlated table referenced from the parent query is advanced to a new row… although currently without regard for whether the referenced column(s) actually have different values in the new table row.

Upgrading to This Release

New Data Format

To implement the storage engine optimizations listed above it was necessary to change the underlying storage format used to serialize some data types, so version 5.1 has a new database format version.  To preserve compatibility, VistaDB 5.1 (and later 5.x versions) can access and write to a 5.0 database and will leave it in that format unless a pack is performed.  This will leave the database accessible to 5.0 versions, but it will not have the storage performance improvements.

As always, to upgrade to the latest data format just perform a pack on the database using the 5.1 (or later) engine in order to unlock the improved performance of the new storage layer.  Once a 5.1 or later engine has packed and upgraded a database it will no longer be accessible to 5.0 versions.  Keeping a backup copy of the database is recommended when performing a pack (and regular backups in general practice) but may be even more advisable when upgrading to a new format since there is no way for applications to reverse the update back to the older format.

Any new (or migrated) database created by a VistaDB 5.1 (or later) engine will use the latest storage format and have the improved storage layer performance but will not be accessible to 5.0 or older versions of VistaDB.

New Assembly Version

Because the file format has changed and the VistaDB engine can be installed in the Global Assembly Cache (GAC) the assembly version has been changed.  This ensures that an application built against VistaDB 5.0 won't accidentally start using the VistaDB 5.1 engine and potentially upgrade its database to a format that the engine it shipped with can't read.  While the number of scenarios where this type of problem could occur are few, the consequences would be confusing and difficult to troubleshoot so the decision was made to prevent them.

To accommodate this assembly version change the assembly versions of the VistaDB Entity Framework providers and other assemblies that reference the engine have been updated as well.  If your references to these assemblies are marked to be version specific you will get a warning when you recompile your application that it can't find the necessary assemblies.  Re-create the references or mark the references as not being version specific to resolve the issue.

Defects Fixed in This Release

All defect fixes were shipped separately as VistaDB 5.0.7, there are no additional defect fixes exclusive to this release.

See Also