Adding a "64-bit" property to the existing 32-bit PostgreSQL 8.2 SMF service versus adding a new SMF service instance (for a 64-bit server) was the subject of discussion in the ARC case for 64-bit PostgreSQL.
A new property seemed like a good idea, but the problem is that (for PostgreSQL) database files created with 32-bit binaries are incompatible with 64-bit binaries (and visa versa). This is why there are separate locations for the data files. If we had created a new 64-bit property, and you enable the service (which creates the database for you), you cannot then change the 64-bit property anytime afterwards (well if you do, the service will fail to start). The property would be "set once only before db creation", which isn't a lot of use really. If you wanted to change the word size of the service (say from the default of 32-bit to 64-bit), you have to delete the database & recreate it. We ultimately decided to have separate services - one for a 32-bit server (version_82) and one for a 64-bit server (version_82_64bit). The PostgreSQL SMF manifest & services are as much examples of how you can manage PostgreSQL, as they are services that you might want to use (hence they're all disabled by default). The customer chooses which service they want to enable - 32-bit or 64-bit (if they want to make use of the larger memory map). Jan S Berg wrote: > 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 > _______________________________________________ > databases-discuss mailing list > databases-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/databases-discuss
