List:Internals« Previous MessageNext Message »
From:Dan Meany Date:August 3 2010 7:08pm
Subject:Re: 64 table join limit
View as plain text  
Like you say, it does need to be indexed, and we have done it for both field orders. 
We do have it in production with good performance and it has provided us with enormous
business flexibility in certain applications.  The only difficulty is the 64 table
limit in mySQL.


--- On Tue, 8/3/10, MARK CALLAGHAN <mdcallag@stripped> wrote:

> From: MARK CALLAGHAN <mdcallag@stripped>
> Subject: Re: 64 table join limit
> To: "Dan Meany" <dan_meany@stripped>
> Cc: internals@stripped
> Date: Tuesday, August 3, 2010, 11:21 AM
> Is there a better way to support
> this? Db servers I care about have
> suffered greatly from such support for schema-less apps. A
> row per
> attribute using the columns (attribute name, attribute
> value) might be
> good when these attributes are to be indexed. Otherwise,
> this can be a
> huge drain on performance.
> 
> On Tue, Aug 3, 2010 at 8:41 AM, Dan Meany <dan_meany@stripped>
> wrote:
> > The 64 table limit on joins was discussed with a
> proposed solution based on the change to key_map in the
> thread 16713 some time ago:
> >
> > http://lists.mysql.com/internals/16713
> >
> > This has become much more of a constraint when
> implementing a partly schemaless design with an attribute
> table (ala couchDb etc.) where you might need a self-join
> for every field in the logical table.  I noticed the
> declaration ulonglong table_map is still in both 5.1 and 5.4
> vs. key_map which is Bitmap<64>.  I wonder if anyone
> has an opinion if this is a safe change to make for
> table_map?
> >
> >
> >
> >
> >
> >
> > --
> > MySQL Internals Mailing List
> > For list archives: http://lists.mysql.com/internals
> > To unsubscribe:    http://lists.mysql.com/internals?unsub=1
> >
> >
> 
> 
> 
> -- 
> Mark Callaghan
> mdcallag@stripped
> 
Thread
64 table join limitDan Meany3 Aug
  • Re: 64 table join limitMARK CALLAGHAN3 Aug
    • Re: 64 table join limitDan Meany3 Aug