On Thu, Nov 24, 2011 at 3:00 PM, Shai Berger <s...@platonix.com> wrote: > While we're all at it, I would like to bring to your attention another > suggested fix for Oracle. The patch attached here tells the backend that if a > fetch operation retrieved less than the requested array size, then no further > fetch attempts are necessary. > > The fix is motivated by our DBA's finding, that many single-row-selects are > followed by double fetches. When I checked the code, I realized that with the > exception of aggregates, this is true for all single-row selects: whether it > originates from qset.get(...) or from qset[j], the QuerySet code adjusts the > SQL and then calls fetchmany in a loop until no results are returned. Since > neither cx_oracle nor the Oracle client library take it upon themselves to > stop such requests, they go all the way to the database.
There is nothing specific to Oracle about this. This optimization should be performed in the query engine, not in the backend. > The Python DB-API[0] says on fetchmany: > """ > The method should try to fetch as many rows as indicated by the size > parameter. If this is not possible due to the specified number of rows not > being available, fewer rows may be returned. > """ > I interpret that as "no rows should be fetched after a call failed to fill the > buffer". Under a loose-enough transaction isolation level, rows may "come into > being" in mid-transaction, but I don't think it is reasonable to expect them > to do so in mid-statement. > > That being said, the problem that this patch fixes is a little hard to test > for; it essentially requires mocking the database library. Also, I'm not sure > this is the right fix; I don't know if other backends have the same issue. If > they do, it might be better to make qset[j] just use fetchone instead of > fetchmany, like the aggregates do; and it might be worthwhile to also change > the qset.get() logic (in a more subtle way -- we don't want to lose the check > for multiple records returned). I think that this is the right approach. Cheers, Ian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
