This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: prepared statements in sqlite3 module
Type: enhancement Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: Mayur.&.Angela.Patel-Lam, ghaering, poq
Priority: normal Keywords:

Created on 2011-09-16 12:34 by Mayur.&.Angela.Patel-Lam, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
unnamed Mayur.&.Angela.Patel-Lam, 2011-09-20 16:40
Messages (4)
msg144129 - (view) Author: Mayur & Angela Patel-Lam (Mayur.&.Angela.Patel-Lam) Date: 2011-09-16 12:34
The sqlite3 module is wonderful, but the one advantage that C/C++ coders have using that system is the ability to use precompiled/prepared SQL statements.  Some SQL databases like Postgresql allow you to precompile statements using special SQL statements (e.g. PREPARE), so there is no need to change the python DBI for those database systems.  But unfortunately, sqlite3 only offers a C/C++ function, which returns a handle to the prepared statement.  I have sought a way to call this from the python DBI, but I simply don't think it's exposed.

Since my application interleaves several SQL commands, depending on the results of the last iteration, I can't immediately use executemany() to obtain maximum performance on my code.  Precompiled statements offer me the best opportunity to optimize.  I can prepare the 2 or 3 most expensive queries in my loop and call them in whatever order I need.  There are some estimates that prepared statements can accelerate complex queries by an order of magnitude, as the parser and optimizers don't need to come into play for every call.

Would you consider an extension to the sqlite3 DBI to expose prepared statements?  Thanks.
msg144221 - (view) Author: (poq) Date: 2011-09-17 21:47
The sqlite3 module already uses prepared statements. Quoting from the documentation:

"The sqlite3 module internally uses a statement cache to avoid SQL parsing overhead. If you want to explicitly set the number of statements that are cached for the connection, you can set the cached_statements parameter. The currently implemented default is to cache 100 statements."
msg144341 - (view) Author: Mayur & Angela Patel-Lam (Mayur.&.Angela.Patel-Lam) Date: 2011-09-20 16:40
Okay, I missed that in the documentation.  I was looking for a handle to a
prepared statement.  I suppose it's hashing on the text of the SQL statement
to determine equivalence?

I'm willing to retract the request.  I need to restructure my code a little
bit to take advantage of this feature.

On Sat, Sep 17, 2011 at 5:47 PM, poq <report@bugs.python.org> wrote:

>
> poq <poq@gmx.com> added the comment:
>
> The sqlite3 module already uses prepared statements. Quoting from the
> documentation:
>
> "The sqlite3 module internally uses a statement cache to avoid SQL parsing
> overhead. If you want to explicitly set the number of statements that are
> cached for the connection, you can set the cached_statements parameter. The
> currently implemented default is to cache 100 statements."
>
> ----------
> nosy: +poq
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue12993>
> _______________________________________
>
msg152553 - (view) Author: (poq) Date: 2012-02-03 20:12
This can be closed.
History
Date User Action Args
2022-04-11 14:57:21adminsetgithub: 57202
2012-02-03 21:06:19georg.brandlsetstatus: open -> closed
resolution: works for me
2012-02-03 20:12:34poqsetmessages: + msg152553
2011-09-20 16:40:27Mayur.&.Angela.Patel-Lamsetfiles: + unnamed

messages: + msg144341
2011-09-17 21:47:25poqsetnosy: + poq
messages: + msg144221
2011-09-16 21:10:00ned.deilysetnosy: + ghaering
2011-09-16 12:34:19Mayur.&.Angela.Patel-Lamcreate