archives again

[Collins Richey]

On 11/20/05, David Bandel <david.bandel at gmail.com> wrote:

[ snips ]
> On 11/19/05, Collins Richey <crichey at gmail.com> wrote:
>
> > > > What brought this up was one of those PostgreSQL vs MySQL questions on
> > > > my local list ...
> >  I suggested that we study Postgres as well. Back came the attitude - who needs Postgres
> > when you have MySQL ...
>
> Who need Linux when you have M$ ...
>
> PHP and MySQL is a recipe for disaster.  PHP has had more security
> problems than most any other software package.  Does PHP have:
>
> a way to "taint" input (similar to Perl's -T)?  If so, it appear no
> one know about it.  Way too many Perl programmers don't use -T for web
> (or CLI or GUI) apps when they should, but at least it's there.
>
> and MySQL is the database answer to M$.
>
> >
> > The one observation I have that makes this gentleman's comment
> > slightly believable came up with CentOS4/RHEL4 where they shipped with
> > a default of selinux enabled but Postgres would not start with the
> > default setting. There soon followed a fix/workaround, but it makes me
> > think that Red Hat didn't care quite as much about testing Postgres as
> > they do about other products. That's a one off.situation.
>
> So since when is RH the standard?  I've considered RH to be the Linux
> answer to M$. Unstable bleeding edge nonsense (perhaps not recently
> with the spinoff of Fedora), but they got the nickname RedCrap for a
> reason.

Yeah, I've always avoided Red Rat like the plague, but now I are one.


> A lot more folks use M$ than Linux on the desktop.  What does that
> tell you?  Marketing hype counts.  And MySQL has been a default
> install on most distros where as Postgres hasn't.
>
> Doesn't help that big blog and search sites use MySQL.  But who cares
> if you get data corruption on a blog containing a bunch of idiots
> non-sensical comments?  Or if you're running a farm of 1000 MySL
> servers that monitor and rebuild each other if one gets
> corrupted/outdated data?
>
> >
> > Given what little I understand about both products, I've never been
> > able to figure out why MySQL became so insanely propular. I just read
> > an article on LinuxToday where a company called EnterpriseDB has
> > developed an interface (commercial not FOSS) that allows Postgres to
> > run pretty much unadulterated Oracle code, and they're certainly not
> > doing that for MySQL..
>
> Because Postgres supports most of the same feature as Oracle,
> Informix, Sybase, etc. MySQL is pure speed (only).  Most of these SQL
> neophites also only use one table vice many.  But when you use many
> tables (as I have, one app has over 50 tables), in MySQL you'd need 3
> queries (a union of 2 natural joins) to perform a single left outer
> join query.  No matter how fast MySQL is, unless the Postgres database
> is huge, without indexes, and never analyzed (to give hints to the
> optimizer) it will be twice as fast as MySQL when an outer join
> workaround is required.
>
> Ask if MySQL requires a vacuum.  Vacuum eliminates deleted rows from
> the db.  These rows are deleted when an updated row replaces it.
> MySQL used to just rewrite the row (aagh, what a _terrible_ idea!
> Imagine an OS crash in the middle of a row rewrite).  _All_ real SQL
> dbs use row substitution to switch changes in.  And transactions are
> vital, especially when updating hundreds of thousands of rows or even
> when updating just a few rows if multiple users might be updating the
> same rows at the same time (which brings up row vs table locking
> issues).
>
> Granted, it's been a long time since I followed MySQL development, but
> I dropped it years ago for the same reasons I dropped M$.
> Improvements be damned, I don't have time to learn hundreds of new
> programs a year.  So I'll be sticking to PostgreSQL and Linux, thanx.
>
> >

Thanks for the responses, David. I'm going to pass the relevant parts
minus some of the personality stuff to our local list. Maybe it will
help answer the question "Why Postgres?".

--
Collins Richey
      Debugging is twice as hard as writing the code ... If you write
      the code as cleverly as possible, you are, by definition, not
      smart enough to debug it.
             -Brian Kernighan