On Mon, Oct 10, 2005 at 12:27:22PM -0500, Jim C. Nasby wrote:
> I think the best way to increase migration from MySQL to PostgreSQL
> would be to find out what the biggest pains are for users attempting to
> migrate and then figure out how we can reduce that pain. In some cases
> these solutions might be adding features to PostgreSQL, but many of them
> might just involve improving existing migration tools.
Well, here's my top of the head list from an RT migration we did. I
don't have my notes handy; this is from memory. Note that most of
the problems came from SearchBuilder, which is what RT uses as an
abstraction layer. See the bottom of this for my "real problem"
analysis.
1. Case insensitivity. You can work around this, of course, but
it is _tedious_.
2. SELECT count(*) is slow. I know, I know.
3. Really huge OR sets pick the wrong plan. My bet is that this
could be tuned away, but it's tough to argue for this when MySQL did
it fast.
4. UNIX domain sockets are _way_ faster than TCP/IP; the same
penalty appears not to be there for MySQL.
5. Developers think in MySQL.
IMO, (5) is the real problem. An application which was,
fundamentally, designed around the SQL-filesystem that is MySQL 3.x
is never really going to use the database in an effective way; and
that likely means that migration is always going to be a very painful
problem.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
--Alexander Hamilton