Re: MySQL index hints

On Thu, Aug 26, 2010 at 12:09 AM, Michael Manfre wrote: > > On Aug 24, 9:30 pm, Russell Keith-Magee > wrote: >> I don't follow your logic here. > > I guess I'm more of the mindset of query hints having as much to do > with the stored data as the schema

Re: MySQL index hints

On Aug 24, 9:30 pm, Russell Keith-Magee wrote: > I don't follow your logic here. I guess I'm more of the mindset of query hints having as much to do with the stored data as the schema and most hints would probably be a premature optimization or specific to a failing

Re: MySQL index hints

On Wed, Aug 25, 2010 at 5:11 AM, Michael Manfre wrote: > I don't think namespacing is a valid objection against query hints. By > design, query hints are specific to a database version and if a > generic django app were to include them, then the author is doing > something

Re: MySQL index hints

I don't think namespacing is a valid objection against query hints. By design, query hints are specific to a database version and if a generic django app were to include them, then the author is doing something wrong or setting the expectation of only supporting a very specific environment. Any

Re: MySQL index hints

On Thu, Jul 22, 2010 at 12:59 PM, Santiago Perez wrote: >> I'd be happy to use raw(); but then you lose len(), slicing, >> pagination, filter chaining, etc. My problem came about because admin >> change lists were unusably slow on large tables. With_hints allowed a >> simple

Re: MySQL index hints

> I'd be happy to use raw(); but then you lose len(), slicing, > pagination, filter chaining, etc. My problem came about because admin > change lists were unusably slow on large tables. With_hints allowed a > simple monkey patch to admin, dropping 2s per page down to ~0.01s. How about a

Re: MySQL index hints

On Fri, Jul 16, 2010 at 10:43 AM, Simon Litchfield wrote: > Russ -- > > Firstly, re namespacing. No worries, let's just keep it RDBMS- > specific, ie -- > > MySQL - with_hints(use={}, force={}, ignore={}) > Oracle - with_hints(index={}, ...) > > That gives plenty of name

Re: MySQL index hints

Simon -- Slicing result sets is clearly the developer's responsibility IMHO. Even with hard limits, MySQL still fails miserably in many situations; hence the proposal to support hinting from the ORM. Russ -- Firstly, re namespacing. No worries, let's just keep it RDBMS- specific, ie -- MySQL

Re: MySQL index hints

On Thu, Jul 8, 2010 at 3:51 PM, Simon Riggs 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

Re: MySQL index hints

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

Re: MySQL index hints

On Mon, Jul 5, 2010 at 11:19 PM, Simon Litchfield wrote: >> I would like to know how you're validating your assertion that MySQL >> is the most used backend. It doesn't match my experience or >> observation. > > Nobody knows for sure. I'd put my money on it though. > >> The

Re: MySQL index hints

On Wed, Jul 7, 2010 at 8:07 AM, Kevin Howerton wrote: >> For a very high traffic project backed by 20+ DB servers > Slightly OT, but MySQL performance related... > > If you are write heavy, there's another issue that I imagine would > bring significant gains on a MyISAM

Re: MySQL index hints

> For a very high traffic project backed by 20+ DB servers Slightly OT, but MySQL performance related... If you are write heavy, there's another issue that I imagine would bring significant gains on a MyISAM setup of that proportion... and possibly other databases to a lesser degree (the locking

Re: MySQL index hints

> I would like to know how you're validating your assertion that MySQL > is the most used backend. It doesn't match my experience or > observation. Nobody knows for sure. I'd put my money on it though. > The fact that this is a MySQL-specific issue is perhaps the biggest > impediment to my

Re: MySQL index hints

On Mon, Jul 5, 2010 at 3:59 PM, 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

Re: MySQL index hints

On Mon, Jul 5, 2010 at 3:08 PM, hinnack wrote: > Thats interesting. > Can you explain, how the search keyword made it into the source? > Entry.objects.filter(headline__search="+Django -jazz Python") > SELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz >

Re: MySQL index hints

On Mon, 2010-07-05 at 00:59 -0700, Simon Litchfield wrote: > I'd be happy to use raw(); but then you lose len(), slicing, > pagination, filter chaining, etc. My problem came about because admin > change lists were unusably slow on large tables. With_hints allowed a > simple monkey patch to admin,

Re: MySQL index hints

On Jul 5, 5:08 pm, hinnack wrote: > Thats interesting. > Can you explain, how the search keyword made it into the source? > Entry.objects.filter(headline__search="+Django -jazz Python") > SELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz > Python IN

Re: MySQL index hints

> 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

Re: MySQL index hints

Thats interesting. Can you explain, how the search keyword made it into the source? Entry.objects.filter(headline__search="+Django -jazz Python") SELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz Python IN BOOLEAN MODE); Seems to be very MySQL specific... regards Henrik On 4

Re: MySQL index hints

On Sun, Jul 4, 2010 at 1:10 PM, Simon Litchfield wrote: > For those of us using MySQL, having large tables, whilst also wanting > queryset goodness -- > http://code.djangoproject.com/ticket/11003 > > It goes a little something like this -- >

MySQL index hints

For those of us using MySQL, having large tables, whilst also wanting queryset goodness -- http://code.djangoproject.com/ticket/11003 It goes a little something like this -- Model.objects.filter(field=value).with_hints('my_index') All those in favour say I. Simon -- You received this message