Hi Sheeri, all
On 11/08/2008, at 10:19 AM, Sheeri K. Cabral wrote:
On 8/10/08, Brian Aker <[EMAIL PROTECTED]> wrote:
Is there any reason why you would ever want
myisam_concurrent_insert disabled?
Yes - http://www.mysqlperformanceblog.com/2006/06/13/myisam-concurrent-insert/
Yep of course, that too.
Anyone have any other favorite variables which should just go?
ummm....global server variables only or also session server
variables and status variables?
old-passwords should die, as should the PASSWORD() function, now
that auth is not done in the MySQL server itself.
Even if someone writes a plugin for MySQL to use a table for auth,
folks shouldn't use PASSWORD().
OLD_PASSWORD() as well, for sure.
obviously: named pipe, socket, shared memory (and
shared_memory_base_name), which may already be out but I figured
they might not be yet...same with sql-
mode.....log_bin_trust_function_creators deals with stored routines
(sp, sfunc and triggers)
The SSL_ variables should go; that should be made a plugin.
I would suggest ditching internal SSL support altogether.
Going with the unix paradigm of combining single-purpose tools, using
stunnel makes good sense.
Also better for speed.
"new" and "old" (I can't make this stuff up, folks....speaking of
which I found a variable called "one_shot" in the 6.0 docs, but
there was no description of what it did, so I filed http://bugs.mysql.com/bug.php?id=38708)
I could explain (from 4.1 onward) but I'm not going to bother ;-)
Let's ditch it
last_insert_id could go -- it causes more problems than it solves
IMO. This will likely be controversial...
Hmm...
We could discuss sequence generation.
lower_case_file_system
lower_case_table_names (just make 'em all case insensitive!)
Always lowercase db/table names into the filesystem, and all compares
case-insensitively. Yes. Excellent.
system_time_zone -- unless it's such a huge win caching that...but
when the server changes time zones MySQL needs to restart. pain!
Well we already discussed that we want to promote UTC and not have
Drizzle do any timezone conversion.
So this var can go as it has no effect on Drizzle operational behaviour.
I forget what was talked about for the character set/collation
stuff, but there are tons of variables for the server/system/
database/table/client/whatever charset and collation, that I'd love
to see whittled down or gone away for something more sane.
If/when Drizzle goes pure UTF-8, this can all be removed. I think I'd
be for that, as it prevents a lot of hassles, even with the slight
performance degredation in some areas of the current codebase. But
that too can be addressed over time.
How often do folks set "flush" to "yes" (and flush_time)? That's a
loser in my book, but kind of obscure and seems that it might be
REALLY needed when needed...but...
This also brings up the q, do we want to remove some "shoot yourself
in the foot" type settings?
I'd also be in favour of losing sql_mode.
Why is there a "license" variable? I mean, seriously. I can
understand the version one (though the "version-comment" drives me
batty! it's either part of the version or not!)
It was introduced for dual licensing (before enterprise) when there
were non-GPL clients talking with non-GPL servers (and locked into
that). There'll be some code on both ends for that. Ugly. Should go.
Cheers,
Arjen.
--
Arjen Lentz, Founder @ Open Query
Training and Expertise for MySQL in Australia and New Zealand
http://openquery.com.au/training/ (ph. +61-7-3103 0809)
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
