Re: [htmltmpl] Re: eWeek Reviews Bricolage

[Sam T. <sa...@tr...>]

On Wed, 11 Aug 2004, David Wheeler wrote:

> To whom did you report them? I don't recall you running into any bugs, only
> features you were used to in MySQL but were missing in PostgreSQL.

On the PostgreSQL mailing-list.  Two that jump to mind which I'm
absolutely sure I reported:

  - pg_dump produces invalid SQL.

  - Indexes don't get used unless you VACUUM ANALYZE your tables.  I'd
    consider documenting this fact in the section on indexes, but it
    would be even better if it would just go away.

If I remember correctly they both got scheduled to be fixed in some
future version.  You could be right that I let some slip and just gave
up after finding workarounds.  That sounds like me, unfortunately!

> >   - MySQL is faster and easier to optimize when it's running slow.
> >     Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM
> >     ANALYZE run-around.
> 
> Huh? This is because MySQL doesn't keep statistics, which long term is to its
> detriment.  

Lies!  MySQL certainly does keep statistics.  It just doesn't require
them to get good use out of most out of its indexes.

> PostgreSQL 7.4 introduced pg_autovaucuum, and it is built-in to the
> server in 8.0, so now it's a no-brainer.

That's good.  I didn't mean to imply that PostgreSQL isn't improving.
I just happen to think that MySQL is more stable at present, and that
it has been more stable in the past.

> > Now, to be fair, PostgreSQL has a lot of features that aren't present
> > in MySQL.  I tend to think most of them aren't all they're cracked up
> > to be, but I understand that a reasonable person can disagree.
> 
> Yep. But this is old hat for you and me, isn't it? ;-)

Sure is.  I don't expect to convince anyone who has already made up
their mind.  But if you ask me why I use MySQL then I don't mind
telling you!  If you don't like my reasons, well, what can I do about
that?

> Hrm, so Krang has embedded SQL like Bricolage?  Pity. I would
> certainly never do that again.

The API classes do.  The CGI layer doesn't and neither do the scripts
in bin/.  I find this to be a pretty reasonable setup and easy to
maintain, but I'm sure there are other reasonable ways to do it.

Actually, this was one of the more difficult design decisions I faced
in Krang.  I spent a couple weeks evaluating OO DB wrappers
(Class::DBI, Alzabo, etc).  Ultimately I decided that they weren't
solving any of the hard problems in Krang, but they would add another
layer of complexity.  The results have been good, but I can't really
say with authority what the alternative would have been like.

Unlike MySQL vs. PostgreSQL.  I've been there, I've done that and I
know the score! ;)

-sam