Consultor Eletrônico

Status: Unverified

GOAL:

The Performance Gains and Caveats of the -v6q Option

GOAL:

-v6q

GOAL:

Startup Parameter

FIX:

In V7 the -v6q client startup option was introduced.
This was intended mainly to instruct the server to use only one index to resolve FOR EACH statements.

Since V6 only used one index to resolve the FOR EACH, performance for the queries is considerably slower than in V7 where we implemented the use of multiple indexes to resolve the query. Using more than one index may be more efficient,but it may change the order in which records are returned.

Another use for the -v6q option that has evolved is for speeding up V6 queries on a version seven database. Running some V6 queries on V7 has proven to be considerably slower when run on V7. As a result, some customers have chosen to run with the -v6q on the client to resolve the queries on one index, thus improving the performance of the V6 code on the V7 database.

The important and undocumented part of this is that using the -v6q from the client is an all or nothing proposition. Although it is not encouraged to blend V6 code with V7 code, sometimes customers are forced to do just this due to timing constraints in migrating an application to a newer version.

The problem with using the -v6q option when mixing V6 and V7 code is that it runs all queries as version six queries, using only one index regardless of the version the procedure was compiled under. This can significantly impact performance of a procedure compiled in a version which uses multiple indexes. If you are going to use the -v6q option with more than just V6 code, please understand that the parameter is not intelligent enough to determine which version of the procedure it is currently running. It simply runs them all as a V6 query and uses one index. The most effective use of the parameter is when running V6 structured queries in V7.