> From: Zbigniew <zbigniew2...@gmail.com> > >> switching from DATE to "more numeric" data type may not be necessary...
I would hope that the query optimizer converts '2014-11-02' to the three-bytes internal representation of DATE before doing the query, in which case, DATE should actually be a tiny bit faster than TIMESTAMP. >> using ENUM instead of VARCHAR can be real performance gain, right? Not just in performance, but it appears to simply be The Right Thing To Do(TM) in your case. (Codd Rule #10: referential integrity.) Consider an insert into a day-of-week column (for instance) that somehow got "Sudnay" in the VARCHAR field instead of "Sunday." Using an ENUM eliminates the possibility of a typo at a more fundamental level than your programming logic. If you do a massive insert with "Sudnay" in the ENUM field, the entire transaction will fail, which is really what you want rather than having to track down "bad data" after the fact, no? If it REALLY is one value out of a known set, it SHOULD be either an ENUM, or a reference to another table. Use the latter technique if you need to add new values very often. > But are you able to estimate, what "boost" can i notice? 5% - or 50%, or > maybe even 500%? Very hard to say. That's like saying, "If I eat well and get enough exercise, will I live 5% or 50% or 500% longer?" Probably more like 5%, but it may FEEL like 500%! :-) If the value is constrained to a set, having it as an ENUM (or reference to another table) will save you grief in many other ways besides boosting performance. :::: Private enterprise, indeed, became too private. It became privileged enterprise, not private enterprise. -- Franklin Delano Roosevelt :::: Jan Steinman, EcoReality Co-op :::: -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
