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 > <ma...@juffo.org<javascript:>> > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/86728052-4e2c-4432-bb00-991ce148386d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
