On Mon, Nov 27, 2000 at 10:03:35PM -0400, Bob Hall wrote:
[ ... ]
harder to learn. Earlier versions had a reputation for corrupting
tables every few months under steady use. Whether this problem
continues in the current version, I haven't heard.
ya, this can be annoying. we saw it with 6.5.x, and after much farting
around, discovered that if we made *absolutely sure* that no INSERTs or
UPDATEs would cause a row to be greater than 8192 bytes in size, the
corruption disappeared. yes, it'd be nice to not have to check, but at
least we can have a stable db. in theory the pgsql backend should be
checking this. i guess someone forgot :-)
i am informed that 7.0.x has fixed this bug, and we're in the migration
process from 6.5.x now. 7.1.x is looking extremely good - no more 8k
row limit.
if anyone has seen corruption in more recent pgsql, i'd certainly like
to hear about it.
If someone has *not* seen corruption in pgsql 7.1 under steady, hard use, I'd like to hear about it. If it has reached the point where I can consider recommending it to clients, I'd certainly like to know about it.
The question is not whether one is better or not, but what you want
to do. If you want a draught animal that can haul anything, go with
PostgreSQL. If you want a race horse that goes fast around specific
types of tracks, pick MySQL.
one question is (at least in the web world, which is what this list is
about): how many sites *don't* really need stuff like transaction
support? sure, you can play games and do tricky stuff but in the end,
its a lot nicer to just be able to go 'begin; ...; ...; end; commit;'
I've used MySQL in commercial apps where transaction support was completely irrelevant. I'm working on a proposal right now where I'm going to recommend a MySQL backend. The client doesn't need transactions, and doesn't need updates or deletes under high concurrency. There are many commercial applications where MySQL is perfectly suited. That's not to say that MySQL is never misapplied by people who don't understand databases.
mysql will certainly be interesting once the transaction support is
tagged "stable".
[ ... ]
difference will become much smaller. Second parties are adding
transactions and row level locking to the basic MySQL package,
this worries me a bit. i don't mean to deride the developers of mysql
or the transaction code, but it seems to me that transactions are fairly
integral to a rdbms, and not the sort of thing you can just "add on"?
I agree, and the developers seem to be having trouble getting MaxSQL (MySQL with transactions) into stable form. People who have compiled the transaction version say it is noticably slower than MySQL. I'm glad that progress is slow, since that increases the probability that the end product will be right. Notice that I pointed out that MySQL with transactions isn't even gama ware yet.
like a car. you can't start with just seats and wheels, you need a
chassis first.
For PostgreSQL, the development team is ironing out the remaining
kinks and turning it into real competition for the commercial DBMSs.
while it may lack some of the features of the commercial DBMSs, i think
it already is very real competition. i'd certainly choose pg over
oracle any day of the week. i find it far more user- and admin-friendly,
and i'm sure i'm not alone.
If they've solved the corruption problem, it is competition.
Bob Hall
Know thyself? Absurd direction!
Bubbles bear no introspection. -Khushhal Khan Khatak