agesys-dev team mailing list archive

[Joe Kinsella <joe.kinsella@xxxxxxxxx>]

Public bug reported:

I am new to Python and oursql. In diagnosing why queries were so much
slower in a Python vs. Ruby application, I noticed you are creating,
using and then discarding prepared statements for EVERY query (see
cursor.execute). As best as I can tell, this is to avoid dealing with
the string interpolation of SQL arguments (e.g. which seems to be
handled with varying degrees of success in MySQLdb module). It seems
though this is a defect, since the two step process of a prepared
statement adds overhead that can be substantial in some use cases. This
overhead is typically only of use if you plan on actually re-using the
prepared statement.

Assuming my understanding above is correct, I would suggest the current
interface should always be dynamic, since you do not intend to cache
statements.

I suspect most Python programmers who switched from MySQLdb do not
realize the additional overhead they incur for executing a query, since
this module defaults to dynamic SQL.

** Affects: oursql
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Agesys
Team, which is subscribed to oursql.
https://bugs.launchpad.net/bugs/1046706

Title:
  Prepared statements used for all queries

Status in oursql:
  New

Bug description:
  I am new to Python and oursql. In diagnosing why queries were so much
  slower in a Python vs. Ruby application, I noticed you are creating,
  using and then discarding prepared statements for EVERY query (see
  cursor.execute). As best as I can tell, this is to avoid dealing with
  the string interpolation of SQL arguments (e.g. which seems to be
  handled with varying degrees of success in MySQLdb module). It seems
  though this is a defect, since the two step process of a prepared
  statement adds overhead that can be substantial in some use cases.
  This overhead is typically only of use if you plan on actually re-
  using the prepared statement.

  Assuming my understanding above is correct, I would suggest the
  current interface should always be dynamic, since you do not intend to
  cache statements.

  I suspect most Python programmers who switched from MySQLdb do not
  realize the additional overhead they incur for executing a query,
  since this module defaults to dynamic SQL.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oursql/+bug/1046706/+subscriptions