--- Dennis Volodomanov <[EMAIL PROTECTED]> wrote: > Yes, after timing both I found that SELECT EXISTS is actually a tiny bit > faster, which does matter when multiplied by thousands of executions in > a row. > > Unfortunately, I still cannot get it as fast as I want - it takes > approximately 1500-2000 ms per approximately 2000-3000 executions. Is > there any way to speed this up even further somehow? The scenario is > that I have a table full of SQL statements that need to be reexecuted > often to check whether they return any results or not (from other > tables). I have all those SQL statements in memory in the application, > so that saves a bit of time, but can I do anything else?
0.6 milliseconds per query is not fast enough? Wow! What's your system doing that it needs to poll the database so often? Unless you want to redesign your application, there's not much you can do except eliminate the parsing overhead. In the table where you store the SQL statements, create a column to hold the MD5 hash value of the SQL and use that as a key to an in-memory hash map of prepared statements, where you create the prepared statement and insert it into the map with the MD5 value as its key if it does not exist. Keep in mind that your prepared statements are tied to the connection on which they were created, so if you have many connections you will need many maps. Use sqlite3_prepare_v2(). ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
