I've been getting pinged about query prioritization because of a
comment I made elsewhere so I might as well explain the idea
:)
If you have a given number of processors, lets say 32, you may
want to reserve a set number across a spectrum of performance.
For instance let us take a fuzzy definition of:
Slow
Fast
Unknown
You could then map half your processors to Fast queries, and then
split your Slow and Unknown queries across your other processors.
That way you could always know that you have enough CPU to handle
Fast queries (or you could give hints that certain queries
matching a pattern should always be fast).
With MySQL you never have costs which are exact before the query
is optimized, namely because the optimizer recomputes the
execution path for each query. This means you do not have stale
data being used for execution, but it means also that the query
is always being …
Sometimes it would be handy if you know how to re-package a MySQL
rpm. You might wonder how this will benefit your system. Well,
for starters, consider if you have custom-built scripts that
needs to be in all the database servers. Also, consider if you
have a standard way of organizing your database structure such as
separating your logs with your data files.
A re-packaged MySQL rpm would come very handy in these situation.
I've used this a lot in my companies and if you don't have a Red
Hat OS, then consider writing a script to handle your automated
MySQL installation.
As my former boss will attest, I have a reputation for being a
bit of a data quality zealot. The storage of data that is unfit
for use leads to many problems, but I suppose that’s another
subject for another day.
It’s tough enough to manage data quality problems introduced by
source code errors, system failures, and requirements
misunderstandings…But a default installation of MySQL introduces
a new and exciting way to give us data quality evangelists fits:
It allows unfit data to be inserted in the database. That’s the
bad news. The good news is that by making a simple configuration
change you can prevent this, and override the setting when you
don’t care.
In a default MySQL installation, the value of the SQL_MODE system
variable is set to ‘’. This allows you to force inserts and
updates that may violate the intended design of the table. This
point is more philosophical than technical, but in a mission …
As my former boss will attest, I have a reputation for being a
bit of a data quality zealot. The storage of data that is unfit
for use leads to many problems, but I suppose that’s another
subject for another day.
It’s tough enough to manage data quality problems introduced by
source code errors, system failures, and requirements
misunderstandings…But a default installation of MySQL introduces
a new and exciting way to give us data quality evangelists fits:
It allows unfit data to be inserted in the database. That’s the
bad news. The good news is that by making a simple configuration
change you can prevent this, and override the setting when you
don’t care.
In a default MySQL installation, the value of the SQL_MODE system
variable is set to ‘’. This allows you to force inserts and
updates that may violate the intended design of the table. This
point is more philosophical than technical, but in a mission …
You can read the full announcement in the news post at phorum.org.
Summary:
When we officially started on 5.2 in March of 2006, we had several goals. I think we achieved most of those. We also accomplished some unplanned things. Our hackathon (me and maurice slept about 8 hours in 4 days I think) at MySQL Conference 2007 helped a lot. Remember, you can help us get there again by donating to our fund.
Some highlitghts:
New Template
New API layers and more hooks
Better MySQL support
Improved bundled modules
New announcement system
New Search, inside and out
In addition to all this, there are things like more caching options, the new hybrid read view, the new feed options (the feed code was rewritten from scratch) and …
[Read more]A
The nice folks over in Luxembourg just posted the schedule for
their Linuxdays 2008 conference.
I`ll be talking about MySQL High Availability
I was at LinuxDays.lu already 2 years ago and I remember it as a nice an cosy conf with an interesting combo of tutorials and conference talks. If you are in the neigborhood its worth the time.
Oh .. and you can also see Matt in action again :)
Address space can be a significant problem on 32-bit mysql
installations. After several IRC discussions attempting to
explain this to some people, I decided to write this post about
it.
What address space is
Each process running on a multitasking virtual memory OS has its
own private address space. This is a range of addresses of a
fixed size. The exact size depends on the CPU architecture, but
on most 32-bit processors it is 32-bits. Intel/AMD chips address
memory in bytes individually, so the maximum capacity of the
address space is 2^32 bytes.
Address space has nothing whatsoever to do with the physical
amount of RAM installed on a machine; you may have more address
space than ram, but critically, you may also have less.
It is not possible to modify or upgrade the address space of a
machine or software program, except by recompiling it for a
different architecture.
How …