On Mon, 2010-07-05 at 00:59 -0700, Simon Litchfield wrote: > > If you can come up with answers to these points, I might get > > interested. 1 and 2 are fairly trivial; I can think of some obvious > > answers for 3, but 4 is the big problem, and will require some > serious > > research and consideration. > > Well, I'm glad you like the with_hints() approach. Items 1-3 are easy. > Re 4 though, every db does it differently. In practice, most don't > need hints like MySQL does <sigh>, because their query optimisers do a > much better job.
The big problem I see is that hints are simply the wrong approach to handling this issue, which I do see as an important one. The SQL optimizer can't work out how you're going to handle the queryset if all you mention is the filter(). SQL being a set-based language the optimizer won't know whether you wish to retrieve 0, 1 or 1 million rows. In many cases it actively avoids using the index for what it thinks will be larger retrievals. The number of rows required from the queryset is an important part of defining the access path. Hints are only required because we didn't specify the queryset in sufficient detail for the optimizer to understand what we wanted. I would say the correct approach here is to use slicing, since this will add a LIMIT clause and provide full usage information to the SQL optimizer about the queryset. Can I suggest an auto-slice parameter so that we can add LIMIT N onto the bottom of every query by default, if a slice is not already defined. That would work for all DBMS. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
