Execution of SQL Commands

Conventional SQL databases have a very simple SQL execution strategy - the SQL command is executed on the one-and-only server.

In a Lava Distributed SQL database network the requirements are a little more complex. When a SQL command is issued from a client application connected to the Primary Server through a Distributed Client, the Distributed Client database has the ability (in principle) to execute the statement.

However, the tables required to execute the statement correctly may not (all) be present on the client. For this reason, the logic to determine the location of execution is as follows :

• If all the tables required to execute the command are present in full on the client, the command is executed on the client.
• If none of the tables required are present on the client, the command is executed on the server.
• If even one of the tables required are either not present on the client or is distributed On-demand, the command is executed on the server.

There is a further complication. The distributed client may not be connected directly to the Primary Server, but to a Satellite Server which, in turn, is executed to the Primary Server. Should this be the case, the command will first be passed to the Satellite Server, where the logic above will be repeated.

Advantages of local execution

In many cases (provided the user's distributed tables have been configured correctly) it is possible to execute the SQL command locally on the client application's Distributed Client database. Should this be possible, several benefits result :

• By avoiding network communication and protocol overhead, the result is returned to the application faster
• Executing the command on the client removes the processing load from the server
• Due to vastly reduced processing requirement on the server, operations which must unavoidably execute on the server experience less delay and contention