Peter Tribble wrote: > On 2/5/08, Jan S Berg <Jan.Berg at sun.com> wrote: >> Hi, >> >> we have made a draft ARC case for integrating 64bit MySQL and the ODBC >> and JDBC Connectors to OpenSolaris: >> >> http://wikis.sun.com/display/WebStack/MySQL64bitARC >> >> Please review and comment > > I thought that it was now usual to supply 64-bit files in the same > package as 32-bit files, rather than creating a separate package?
Correct, so will update for putting them in the same package, as well as creating the amd64 and sparcv9 directories with symlink from 64 > > Should the bin directory contain both 32 and 64-bit subdirectories > and select the optimal binary using isaexec? (I don't know the answer, > I'm just throwing this one out there.) How to find the optimal binary? I guess that will be up to how you size or use your database. > > Why have a separate service for 64-bit? Why not just have one service > and either choose the optimal server (either by isaexec as above, or > by the method script)? Or maybe an SMF property to select the > appropriate binary? I would find it terribly confusing to have different > services. We made the service like specified for PostgreSQL 64bit, but using a property is a good idea. Does anybody know if there is any Solaris standard for using property vs extra service, or that is entirely up to the application? Since the default config file for MySQL have quite small sized database the default service might then be 32bit. If you and others have experience that 64bit will be faster in most cases (also with the default my.cnf), that should be default if available. > > Likewise, why have a different location for the data files? > > (A technical question - are the data files incompatible between > 32 and 64 bit servers?) Also here we did the same as PostgreSQL, and I'm not aware of the internals of the MySQL datafiles to know if there are any difference. > > Certainly on x64, I *always* run mysql servers in 64-bit, as the > performance boost is noticeable - I haven't noticed much difference > on sparc. > ok, do you use big memory-based databases, or this is your impression also for smaller databases? Thanks, Jan S
