Here's an accepted ticket to allow the use of prepare statements: https://code.djangoproject.com/ticket/20516
On Wednesday, November 27, 2013 10:35:09 PM UTC-5, est wrote: > > Hi Russ, > > Since 1.6 has pooling support now, what do you think of prepared > statements? > > I strongly suggest we add them. It will make Django faster in large > projects > > Django may not want to be the whole stack but it's pretty much the fullest > stack in Python world now. > > On Tuesday, 5 April 2011 23:40:44 UTC+8, Russell Keith-Magee wrote: >> >> On Sat, Apr 2, 2011 at 10:04 PM, Marti Raudsepp <[email protected]> wrote: >> > Hi list, >> > >> > I wrote a proof of concept patch to add prepared statement support to >> > Django for the PostgreSQL backend. Note that it's just a hack to see >> > if this approach could work at all, I know it's badly written. :) >> > >> > The patch is quite simple and so far has worked with all queries >> > generated by Django, for a few different applications. It added a >> > noticeable speed boost, though I haven't done any repeatable >> > benchmarks. The main advantage is skipping redundant planning stages >> > of similar queries -- especially for web pages which may involve >> > complex queries -- many JOINs etc -- but only fetch a page of 25 rows. >> > >> > Here's the hack: >> > >> https://bitbucket.org/intgr/django-queue/src/308dee4377c6/prepared_initial.patch >> > Screenshot in action: http://ompldr.org/vODIzdQ/django_prepared.png >> > >> > Now I'm wondering how to approach a solution that would be mergeable >> > into Django core. >> > >> > I get the impression that Django core developers have been opposed to >> > built-in connection pooling. However, prepared statements are mostly >> > useless without persistent connections. Is there any chance that >> > prepared statements would be accepted into core or is this a show >> > stopper? I'm willing to study Django's internals and take on a fair >> > bit of work to implement this feature. >> >> To clarify -- we've historically been opposed to adding connection >> pooling to Django is for the same reason that we don't include a web >> server in Django -- the capability already exists in third party >> tools, and they're in a position to do a much better job at it than us >> because it's their sole focus. Django doesn't have to be the whole >> stack. >> >> In principle, I am (and, I suspect the same is true of most of the >> core team) open to any suggestion that exposes a performance feature >> of the underlying data store. However, absent of details, it's >> difficult to say whether a proposal would gain traction. >> >> If it's a feature that is only of benefit in pooled environments, the >> barrier to entry will be higher. However, it might be enough to >> stimulate some discussion into how to improve Django's support for >> connection pooled environments -- especially if you can demonstrate >> some real-world performance benefits. >> >> Acceptance will also depend on the invasiveness on the change you're >> proposing -- if you need to gut SQL compilers to make it work in an >> elegant way, the level of enthusiasm probably won't be high. >> >> The user-facing API will also matter -- how do you propose to wrap the >> underlying feature in a mechanism that makes sense in ORM terms. >> >> It's also worth pointing out that proposals to add APIs are generally >> looked upon more favorably than specific feature additions -- >> especially for 'edge case' improvements. Adding a feature means the >> core team inherits a feature we have to look after; adding an APIs >> lets others implement and maintain the features, and we just have to >> keep the API consistent. I don't know if this approach will be viable >> in your case, but it's worth considering. >> >> So, the answer is a definite "maybe" :-) If you can provide some more >> details, we might be able to provide a more definitive answer. >> >> Yours, >> Russ Magee %-) >> >> -- 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/20e8012c-4151-45cf-9197-a9d96c867633%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
