On 03/26/2014 06:06 AM, Curtis Maloney wrote:
Further, as an "expert" feature, would it be unreasonable to
limit its use to cases where you know it will benefit, but
also only be used in a single connection? True, this limits
its use cases somewhat, but it's still available when of benefit.
What do you mean by "single connection", persistent connections
are single connections and as you said above prepared statements
are local to the connection/session anyways…
And I would expect the prepared statement to persist between requests
in that case.
If I thought we could rely on DB dis/connect signals [maybe we can, I
don't know yet] we could teach prepared statements to track that and
re-prepare themselves on first use.
Just throwing ideas out there... seeing which ones excite :)
Django must know which connections have which statements prepared, and
Django must also know the name for each prepared statement.
We can do this by having a map of SQL for the statement -> name of the
prepared statement in the connection. On connection close the known
statements are cleaned. An alternate way to do this is to have a
connection -> prepared statement name map in the statement object
itself. In that case connection close signals must be used to clean the
map. This might be a cleaner design as connection object doesn't need to
know about prepared statements. As a bonus we don't need to map SQL to
statement names. The problem being that the same SQL doesn't necessarily
mean we are executing the same plan (for example changes to search_path
can cause problems here).
So, when you do ps = qs.prepare() you get a prepared statement object
which knows the SQL needed for execution. When you do ps.execute() the
statement object will check the used connection for existing prepared
statements. If none exists, PREPARE is issued. If one exists, then the
statement is reused.
I kind of like the ps = connection.prepare(qs) syntax. But this doesn't
really solve anything, the connection variable is thread local, so doing
ps = connection.prepare(qs) doesn't mean that the prepare is in effect
in other threads. We still need to know which connections have which
statements prepared. So, nothing is actually solved this way.
As for the foo=None/foo__isnull=True problems - I think we can do one
step better than just documenting these cases, we can actually check if
the given parameters lead to incorrect plan and raise an error on
execute. I don't think we can prepare different plans for different
statements - doing so can potentially mean preparing exponential amount
of statements. We can't easily prepare different plans on execute either
due to the way Django's QuerySet construction works.
- Anssi
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/53328CD8.9040100%40thl.fi.
For more options, visit https://groups.google.com/d/optout.
