List:General Discussion« Previous MessageNext Message »
From:Christopher R. Jones Date:May 31 2000 1:49am
Subject:Re: Forced to move to Postgres :(
View as plain text  
I can echo some of the sentiments below.  I first tried to install and use 
Postgres but gave up because of my unfamiliarity with sql databases and 
Unix/Linux (I did have Linux up and running but found the Postgres install 
manual "unfriendly").

So I decided to use MySQL for my first SQL project.  I found both the 
manual and the user groups much more "friendly" than the Postgres 
counterparts.

After about a year of MySQL experience, I experimented with 
Postgres.  Without my previous experience with MySQL, I would not have 
succeeded with Postgres.  The install on Solaris was particularly 
painful.  I did manage to get Postgres installed and I mimicked the MySQL 
database I had developed.  I also found the speed slower than with MySQL.



>MySQL and Postgres are both fine pieces of software, but I prefer MySQL as
>well.  It's much more user (where the user is a programmer) friendly.
>
>I can mention a few "gotchas" when it comes to moving from MySQL to
>Postgres...
>
>* A row in Postgres can only be 8kb.  This is a huge flaming pain.
>   And the BLOB support is not at all transparent!  BLOBs are very hard
>   to deal with.  The TOAST project is helping to make this easier, but
>   it will be several months at best before it's available, in e.g. Pg 7.1
>* "alter table" isn't nearly as command-rich in Pg as it is in MySQL.
>   Yeah, so a lot of MySQL's 'alter table' commands are really wrappers
>   around "create table, copy table, delete table, rename table", etc...
>   At least they're done automatically!  That's nice.  In Pg, if you want
>   to do something as simple as drop a column from a table, you need to
>   go through this annoying process by yourself.
>* The documention for Pg on its website, while complete, isn't organized
>   in anywhere near as helpful as way as the documentation for MySQL.
>   You spend time trying to find things, and then you'll spend time scratching
>   your head wondering what kind of crackhead simian decided to put X in
>   _that_ chapter.
>* Pg is so slow that it will make you want to eat your spleen.  The case
>   where this was most obvious to me was when I wrote a Perl program that
>   took in a text file with about 60k lines, split it all up, and for each
>   line wrote a row in about 4 different Pg tables.  Yeah, there were a lot
>   of indices and whatnot involved.  The import on a Celery 400 took about
>   7 hours.  Then, we tried doing the same thing on MySQL -- took about 5
>   minutes.  Of course, ref. integrity, foreign keys, etc. under Pg is what's
>   to blame here, but still, this stank.
>* Pg doesn't support SQL 'join' syntax.  Ouch!  So much for Pg being SQL92
>   compliant.  [This is one of the things about MySQL that I really like...
>   even if it would be better if it handled 'cube' and 'rollup', too :-) ]
>* The lack of equivalents to 'mysqlshow' and 'mysqldump' bugs me.  Maybe
>   there's a command line invocation of 'psql' that would do the job, but
>   if ever I learned it I've forgotten what it would be.  And sometimes, it's
>   nice to just have a simple command I can fire off.
>* The psql interface to getting descriptive information re: tables, etc.
>   is just crummy.  Get ready to use "\d..." a whole lot.  Please, just
>   "describe table" me!
>* Considering 'sequences' to be their own objects, mainly divorced from
>   the columns and tables they're ostensibly attached to, gets really
>   cumbersome to manage.
>* The output of a database dump is _really_ hard to read/follow, mainly
>   because of the 'create sequence' stuff.  If you want to know how to
>   recreate just _one_ of your tables, you have to fish all over the output
>   of the dump to figure out how to do that.  It doesn't even have the
>   'courtesy' to clump all info needed to create a given table together
>   in one place.  (Of course, given the strong ref. integrity, it's possible
>   that this can't be done.  Which would still make it inconvenient.)
>
>I'm sure there are a few more things re: Pg that bug the heck out of me.
>but that's all I can think of now.
>
>Don't worry... it's not all bad... transaction are really nice to have.
>(That's why we're using it.)  And the ODBMS features can be fun to play with
>sometimes.
>
>Cheers,
>Richard
>
>----------------------------------------------------------------------------
>  Richard Dice * Personal 514 816 9568 * Fax 514 816 9569
>  ShadNet Creator * http://shadnet.shad.ca/ * rdice@stripped
>  Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/
>      "squeeze the world 'til it's small enough to join us heel to toe"
>          - jesus jones
>
>--
>---------------------------------------------------------------------
>Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
>posting. To request this thread, e-mail mysql-thread38805@stripped
>
>To unsubscribe, send a message to:
>     <mysql-unsubscribe-cj=interlog.com@stripped>


Christopher R. Jones, P.Eng.
14 Oneida Avenue
Toronto, Ontario M5J 2E3
Tel. 416 203-7465
Fax. 416 203-3044
Email cj@stripped


Thread
Forced to move to Postgres :(John Steele30 May
  • Re: Forced to move to Postgres :(Richard Dice31 May
    • Re: Forced to move to Postgres :(Christopher R. Jones31 May