On Thu, Jul 8, 2010 at 3:51 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > 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. >
That's categorically untrue. One of the major functions of an optimizer is too try to figure out the approximate result size so it can better establish index vs. data cost. > 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. > Uhh, querysets don't really generate SQL that's in any way different from what a normal person would write. > 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. > And auto_slice parameter to what exactly? > -- > 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. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
