I've been using Slony for years, and while it's not the simplest nor easiest replication to setup, it works, and it works very well, within it's domain of functionality. Yeah, I look forward to hot standby servers in a year or two, but til then, I guess I'll keep using slony.
Actually you kinda have it backwards on "what could go wrong". PostgreSQL has a more unix like philosophy, in that it gives you lots of small sharp tools you can use to build a solution to any problem. MySQL, instead of providing these tools, builds a custom but non-standard SQL answer to each and every problem, that mostly works for most people, and when it doesn't oh well, that's what you get.
begin; select * from table where id=$a for update ; -- (check number of rows returned if > 1 then) update table set yada=$b where id=$a; -- else insert into table values ($a,$b); -- if no errors musta worked commit;
turn it into a function (pick your favorite language if you don't wanna learn plpgsql) and it's all wrapped up and ready to go. And, if that doesn't do exactly what you want, you can CHANGE IT. Something you can't really do with MySQL without forking the code base.
No, it's not. Whoever told you that lied. The official front end to pg_dump is bash. or csh, or tsh, or ksh. And yea, if you can't drive a database without pointy clicky you should get a job with lots of round, non-sharp objects so as not to hurt yourself or others.
Your arguments ring hollow. In PostgreSQL, using schemas within a database, you get the same basic functionality that MySQL does. I.e. what is a database to MySQL is a schema to PostgreSQL. And you can do cross db / cross network queries, but they are uglier since you have to use dblink or pl/proxy.
OTOH, if you crank up innodb and start doing crossdb transactional queries, guess what? They're not really transactional. Half the transaction can fail and half can succeed and your data is now incoherent.
I have to say I find pgsql far more flexible than MySQL. And you can't put ACID in the app. Sorry, but whoever told you that works lied to you.
Also, take a MySQL server in mid transaction with it's wonderful mixed table design, and pull the power plug / trip a circuit breaker / have some idiot at the hosting center power everything down and you can spend a day or two bringing it back up and restoring your data. I'll just turn my PostgreSQL server back on and keep going.
How many pl languages does MySQL support? I can name over a dozen for pgsql.
Also, I'd rather my database yell at me for trying to insert "stan" as a date and just silently turn it into '0000-00-00'. Or try to insert 123876348763 into an int4 and have it silently truncate to 2^31-1 on me. But hey, that's some flexibility, eh!
If you're just running RAID1 the CPU overhead is so small as to be nearly unmeasurable. In fact, the I/O bandwidth will be a problem before the CPU is in a sw RAID1 setup. RAID5 has gotten rather more efficient with time, and typically uses 5% of one core on a multi-core machine nowadays.
Exactly. We have two file servers with 8 and 16 1TB drives each, but our big database servers are running 16 146Gig 15k5 Cheetahs on a very fast RAID-10 controller because we only need to store a few hundred gig in the db, but we need to get to it fast, and with good parallel performance.
The real advantage the Amiga had was that it supported TRUE pre-emptive multitasking, something PCs still cannot really do well today. And it did it all with a 7.2MHz CPU, not a 2200MHz CPU. Which is why here, in the year 2009, on a dual 1.8GHz cpu machine, I can watch the cursor just hang while I type for a few seconds at a time while some non-critical process steals all the cpu time. On an Amiga, I'd never see that happen.
Yep, the 68000 had a 16 bit data bus and a 24 bit address bus. The 68008 had a single 8 bit data and address bus that was multiplexed I believe. The 68k family was a beautifully designed chip. 8 GP data and 8 GP address registers, all 32 bit wide. No paging modes, no crazy segmentation or any of that crap. Just pure 32 bit designs (internally) with various 8/16/32 data / address busses on the outside.
On the Amiga, if you ejected a floppy that wasn't cleanly the OS would demand you reinsert the disk, and then would proceed to flush out the tracks again to the disk. Since the Amiga always wrote an entire track at a time, it was no big deal that one had been half-written when you pulled the disk and it just wrote the whole track again. I used to show Mac and PC users this trick all the time. It was pretty cool.
Moving the 6 key was an unforgivable sin. I used to buy US Logic Ergos which had the 6 on the right hand side where it belonged, but I haven't seen them for a few years now.
Seriously, it was the first commercially produced blitter! It allowed the Amiga to multitask smoothly and reliably with only 256k of ram. It had a huge impact on gfx chipsets to come after it.
I have made sure that no one I know buys Suse as long as Novell has that stupid partnership with Microsoft. If they renounce it, tear up their contract and dance a jig, I might take them back. Til then, I run RedHat, Debian and Ubuntu. No need for any of the crap Novell is peddling.
I'll play some nice slow Irish songs about people drowning on a ferry for Novell, but I won't give them one thin dime. They're whores, and not the good kind.
Wow, it's been almost 10 years since I had a subscription to MSDN. Keys under MSDN back in the day were great, you could instlal multiple versions on multiple machines all with the same key, and build test farms and on and on before you headed to production.
Nowadays, that's pretty much how linux works. Want a test farm on RHEL? Just install CENTOS .
Xerox didn't try to sue Apple. They threatened them with a fraud lawsuit for claiming they invented the gui interface, and apple backed down from their lawsuit with MS because of that threat.
Xerox has a very actionable position, and Apple knew it.
I've found that a GOOD sysadmin costs more than an average programmer, and often you only have one or two sysadmins, even for a large shop, so you can afford to pay more.
Imagine something the size of amazon, google or ebay. There, a 10% performance boost in software could result in saving a million dollars in yearly operation / admin costs.
It just has them on a different scale and there's a different release. If you look through the past release notes for pgsql, you'll see that occasionally one release would come out with some horrific server crashing bug, get reported and get fixed.
Now, the timeframe is what is the key. For MySQL there are server crashing bugs that have been in place since 2003 or before.
For PostgreSQL, once such a bug is documented and reproduce-able, it is generally squashed in hours, days, and occasionally, for really complex problems, in a week or so.
Slashdot Mirror
I've been using Slony for years, and while it's not the simplest nor easiest replication to setup, it works, and it works very well, within it's domain of functionality. Yeah, I look forward to hot standby servers in a year or two, but til then, I guess I'll keep using slony.
Actually you kinda have it backwards on "what could go wrong". PostgreSQL has a more unix like philosophy, in that it gives you lots of small sharp tools you can use to build a solution to any problem. MySQL, instead of providing these tools, builds a custom but non-standard SQL answer to each and every problem, that mostly works for most people, and when it doesn't oh well, that's what you get.
begin;
select * from table where id=$a for update ;
-- (check number of rows returned if > 1 then)
update table set yada=$b where id=$a;
-- else
insert into table values ($a,$b);
-- if no errors musta worked
commit;
turn it into a function (pick your favorite language if you don't wanna learn plpgsql) and it's all wrapped up and ready to go. And, if that doesn't do exactly what you want, you can CHANGE IT. Something you can't really do with MySQL without forking the code base.
"SQL Server is better than Postgres, period, and has tons of features that Postgres doesn't"
[Citation needed]
You work for idiots, and should really start looking for a better job. Seriously.
Have you used a recent version of pgsql with the windows installer? It's really quite nice.
No, it's not. Whoever told you that lied. The official front end to pg_dump is bash. or csh, or tsh, or ksh. And yea, if you can't drive a database without pointy clicky you should get a job with lots of round, non-sharp objects so as not to hurt yourself or others.
s/inefficient/reliable/
Your arguments ring hollow. In PostgreSQL, using schemas within a database, you get the same basic functionality that MySQL does. I.e. what is a database to MySQL is a schema to PostgreSQL. And you can do cross db / cross network queries, but they are uglier since you have to use dblink or pl/proxy.
OTOH, if you crank up innodb and start doing crossdb transactional queries, guess what? They're not really transactional. Half the transaction can fail and half can succeed and your data is now incoherent.
I have to say I find pgsql far more flexible than MySQL. And you can't put ACID in the app. Sorry, but whoever told you that works lied to you.
Also, take a MySQL server in mid transaction with it's wonderful mixed table design, and pull the power plug / trip a circuit breaker / have some idiot at the hosting center power everything down and you can spend a day or two bringing it back up and restoring your data. I'll just turn my PostgreSQL server back on and keep going.
How many pl languages does MySQL support? I can name over a dozen for pgsql.
Also, I'd rather my database yell at me for trying to insert "stan" as a date and just silently turn it into '0000-00-00'. Or try to insert 123876348763 into an int4 and have it silently truncate to 2^31-1 on me. But hey, that's some flexibility, eh!
If you're just running RAID1 the CPU overhead is so small as to be nearly unmeasurable. In fact, the I/O bandwidth will be a problem before the CPU is in a sw RAID1 setup. RAID5 has gotten rather more efficient with time, and typically uses 5% of one core on a multi-core machine nowadays.
1: Single data points do not a trend define
2: Your post argues more for taking regular backups than anything else.
Exactly. We have two file servers with 8 and 16 1TB drives each, but our big database servers are running 16 146Gig 15k5 Cheetahs on a very fast RAID-10 controller because we only need to store a few hundred gig in the db, but we need to get to it fast, and with good parallel performance.
The real advantage the Amiga had was that it supported TRUE pre-emptive multitasking, something PCs still cannot really do well today. And it did it all with a 7.2MHz CPU, not a 2200MHz CPU. Which is why here, in the year 2009, on a dual 1.8GHz cpu machine, I can watch the cursor just hang while I type for a few seconds at a time while some non-critical process steals all the cpu time. On an Amiga, I'd never see that happen.
Yep, the 68000 had a 16 bit data bus and a 24 bit address bus. The 68008 had a single 8 bit data and address bus that was multiplexed I believe. The 68k family was a beautifully designed chip. 8 GP data and 8 GP address registers, all 32 bit wide. No paging modes, no crazy segmentation or any of that crap. Just pure 32 bit designs (internally) with various 8/16/32 data / address busses on the outside.
On the Amiga, if you ejected a floppy that wasn't cleanly the OS would demand you reinsert the disk, and then would proceed to flush out the tracks again to the disk. Since the Amiga always wrote an entire track at a time, it was no big deal that one had been half-written when you pulled the disk and it just wrote the whole track again. I used to show Mac and PC users this trick all the time. It was pretty cool.
Moving the 6 key was an unforgivable sin. I used to buy US Logic Ergos which had the 6 on the right hand side where it belonged, but I haven't seen them for a few years now.
Seriously, it was the first commercially produced blitter! It allowed the Amiga to multitask smoothly and reliably with only 256k of ram. It had a huge impact on gfx chipsets to come after it.
I have made sure that no one I know buys Suse as long as Novell has that stupid partnership with Microsoft. If they renounce it, tear up their contract and dance a jig, I might take them back. Til then, I run RedHat, Debian and Ubuntu. No need for any of the crap Novell is peddling.
I'll play some nice slow Irish songs about people drowning on a ferry for Novell, but I won't give them one thin dime. They're whores, and not the good kind.
If you want performance, avoid RAID-5 and go straight to RAID-10. RAID-5 has horrible write performance.
There's still no way of being sure your fibre and T1 are not in the same tube. Look up Sonet rings.
Wow, it's been almost 10 years since I had a subscription to MSDN. Keys under MSDN back in the day were great, you could instlal multiple versions on multiple machines all with the same key, and build test farms and on and on before you headed to production.
Nowadays, that's pretty much how linux works. Want a test farm on RHEL? Just install CENTOS .
Except modern distros already have most of these features.
troll rating: 1/10
Xerox didn't try to sue Apple. They threatened them with a fraud lawsuit for claiming they invented the gui interface, and apple backed down from their lawsuit with MS because of that threat.
Xerox has a very actionable position, and Apple knew it.
I've found that a GOOD sysadmin costs more than an average programmer, and often you only have one or two sysadmins, even for a large shop, so you can afford to pay more.
Imagine something the size of amazon, google or ebay. There, a 10% performance boost in software could result in saving a million dollars in yearly operation / admin costs.
No, swappiness=0 is NOT the same as running with swapoff -a. The formula for swap tendency is:
tendency = mapped_ratio / 2 + distress + vm_swappiness
As you can see, it's an additive factor, not multiplicative, so no, it doesn't turn off swapping, just discourages it.
It just has them on a different scale and there's a different release. If you look through the past release notes for pgsql, you'll see that occasionally one release would come out with some horrific server crashing bug, get reported and get fixed.
Now, the timeframe is what is the key. For MySQL there are server crashing bugs that have been in place since 2003 or before.
For PostgreSQL, once such a bug is documented and reproduce-able, it is generally squashed in hours, days, and occasionally, for really complex problems, in a week or so.