'Preparing' SQL Statements And Specifying SQL Statement Time-outs: Difference between revisions
(Created page with "= THIS PAGE IS WORK IN PROGRESS = '''This page is currently being worked on. Please come back later to this page when you have been notified that it is finished!''' ==Overvi...") |
|||
| Line 19: | Line 19: | ||
Every <code>DbCommand</code> that is run against the DB has got a time-out associated with it. If the command takes longer than the time-out, the ADO.NET provider for the RDBMS that we are connected to will throw an Exception. | Every <code>DbCommand</code> that is run against the DB has got a time-out associated with it. If the command takes longer than the time-out, the ADO.NET provider for the RDBMS that we are connected to will throw an Exception. | ||
In case of the PostgreSQL RDBMS we use the Npgsql ADO.NET provider, and this throws an | In case of the PostgreSQL RDBMS we use the Npgsql ADO.NET provider, and this throws an Exception when a command takes longer than the default, which is 20 seconds: <code>Npgsql.NpgsqlException: ERROR: 57014: canceling statement due to statement timeout</code> | ||
'''TODO''' | '''TODO''' | ||
Revision as of 06:35, 20 March 2015
THIS PAGE IS WORK IN PROGRESS
This page is currently being worked on. Please come back later to this page when you have been notified that it is finished!
Overview
This page deals with the advanced DB access topics of Prepared Statements and custom SQL Statement time-outs. Please note that both are used and needed only in special circumstances.
Prepared Statements
'Preparing' a SQL query lets the software engineer optimise the performance of frequently issued queries.
What a RDBMS does when it encounters a 'Prepared' SQL query is that it 'caches' the 'query execution plan' and uses this cached information in subsequent calls. Since the creation of a query execution plan takes time, and since spending that time is no longer needed in subsequent runs of the same query, it makes subsequent runs of the same SQL query faster. While the caching of the 'query execution plan' takes a bit of time when the SQL statement gets 'prepared', this is one-off and pays off with subsequent calls to the same query.
A SQL query that uses Parameters and gets 'prepared' is treated as 'prepared' even with varying values for the Parameters and hence fully benefits from the speed-up that a Prepared Statement can yield! This is in contrast to SQL queries whose query strings get constructed 'on-the-fly' (by string concatenation) and which don't use Parameters - 'preparing' such SQL queries does not only not yield better performance, but worsens performance as the caching of the 'query execution plan' takes a bit of time and that time is lost as there is no benefit to be reaped from the caching.
Prepared Statements are not supported by all RDBMS, but should simply be executed in a non-prepared way in case a RDBMS doesn't support it. PostgreSQL definitely supports Prepared Statements.
Customising SQL Statement Time-outs
Every DbCommand that is run against the DB has got a time-out associated with it. If the command takes longer than the time-out, the ADO.NET provider for the RDBMS that we are connected to will throw an Exception.
In case of the PostgreSQL RDBMS we use the Npgsql ADO.NET provider, and this throws an Exception when a command takes longer than the default, which is 20 seconds: Npgsql.NpgsqlException: ERROR: 57014: canceling statement due to statement timeout
TODO