Now, the reason I wouldn't use PostgreSQL in some instances, PostgreSQL still does not have any clustering features that I am aware of.
It sure does: * Slony-I: master-slave, table-level backup. Works across postgresql versions, which means it's very convenient to use to upgrade. Very good software, well tested in live environments (that's what serves the.org in slashdot.org, and every other.org or.info). * PgPool: Query based replication software and network management software. This can work as multi-master by distributing queries, or work with Slony. * Also, 8.1 has the very nifty feature called "Two Phase Commit" (a.k.a. 2PC). This allows network management software to synchronously commit on multiple machines to create a multi-master solution.
gives real-world usable examples of each documented function,
If something is lacking in the documentation, please write to the mailing lists. I'd be happy to write a few documentation pages in my spare time. However, what might be obvious to a PostgreSQL person might not be to someone coming from another database background. So, I don't know what about the documentation needs work.
If you really don't care about transactions, in PostgreSQL you can always turn fsync off and put the logs on a RAM disk. That will be fast but unsafe, just like you're talking about.
There are a few things going on. First of all, Access is two things, a frontend and the Jet database engine. The frontend isn't really what we're talking about, because you could hook that up to MS SQL or PostgreSQL if you wanted.
Jet, I don't really know. I've heard with even a few concurrent accesses it slows to a crawl. But also, in the short time I used it, seemed to have sane behavior when I issued SQL commands: errors where I expect, otherwise the expected result. I can't say the same for MySQL.
Microsoft sells Access as what it is: a few users only, small databases. When you start using it for a workgroup in an office of, say, 20 people, Microsoft will happily upgrade you to SQL server without excessive hassle (I've heard some bad stories, but in the simple case an upgrade will be smooth).
So it's hard for me to criticize Jet too much, because it's part of the overall MS solution. Any complaints and the obvious answer would be "you should have that on SQL Server". Sort of like if you download an application and select the "store this in a flat file" option instead of entering your JDBC connection info.
That being said, I fortunately have not had to work much with Access, so maybe I dodged a few bullets without knowing it.
A lot of benchmarks are published using MyISAM, and a lot of anecdotal evidence that's passed around refers to MyISAM, because it's the default. When people hear about these results, they assume that all of MySQL is fast. When people hear about transactions, they assume all of MySQL has transactions.
I have not seen anything that demonstrates that InnoDB is faster than PostgreSQL in the general case. In fact, InnoDB employs a lot of the same design as PostgreSQL tables. InnoDB uses MVCC-like technology, and a VACUUM-like garbage collection process called "purge". For most types of operations, InnoDB will be similar in performance to PostgreSQL.
I'm not saying that InnoDB is slow. I'm saying that MySQL AB uses deceptive marketing. They are very successful at marketing by using MyISAM as the default, so that anecdotal evidence about speed are always very positive toward MySQL, and then when someone wants transactions then then MySQL must pull the switcharoo on the table type.
It's like you walk into a store because they advertise one price and it's cheaper than the competition. Then you get there and the product doesn't come with a power adapter, so you have to fork over an extra $5. By the time you leave, the price was the same.
You make a good point. As with anything, it depends a lot on the situation. If that works for you, and you control the entire code base, you're in good shape. Frameworks can help prevent inconsistent database state. And there is a certain redundancy to implementing the check in the database. However, note that since PostgreSQL has already written a date type, and you already declared your column as date in either database, it's no additional work to use, and it's not like it's a performance penalty.
Also, consistency checking can still be helpful. If the coder is slightly lazy for a moment and during testing you get inconsistent data in the database, it's really hard to extract that data out and get it back to a consistent state. If you have good development practices, this may never happen. But it's very annoying when it does happen.
Code can be stopped, fixed, and restarted, but the data in the database represents long term application state, and if that gets inconsistent it can do a lot of damage.
That being said, I don't claim to always program every business rule into the database for 100% consistency. But doing the easy stuff can go a long way: check constraints, a trigger or two, foreign keys, and type checking (which is generally not any additional work).
A lot of people use PHP/MySQL. One PHP page inserts bad data, another tries to access that bad data. It might not be multiple applications, but it's distinct operations within one application. It's a lot easier to debug if it throws an error on the page that tries to insert the bad data, because then you know exactly what caused the error. If you're just staring at bad data in the database already, you have no way to know where it came from.
If a programmer's code was tight then that person wouldn't have this problem. MySQL does just what is supposed to do, which is store data.
What you're saying is that every application should have to trust not just the database and DBAs, but every other application attached to the database.
That makes it hell to find bugs that insert bad data. In PostgreSQL, you can set it up so that the application which has the bug gets the error. In MySQL, the bug might not be discovered until another application gets confused by the bad data. Even if the second application properly detects the error, it has no information to help you find the source of the bug.
Interesting information, but just because the German High Court says that February 30th is a date doesn't mean it is.
If you are a bank there are probably lots of date-oriented laws by which you must abide. If a bank needs a special date type where every month is 30 days, they can make a custom type in PostgreSQL that handles it according to local laws.
By the way, if every year has 360 days, isn't there drift due to leap years?
No, my complaint is that the features are advertised as being present, yet each feature is highly conditional. It's deceptive.
PostgreSQL is complete. If they advertise a feature, it works fluidly in conjunction with all the other features they advertise.
What if you bought a car? "It is fast" and "it has airbags". Well, what if you find out the hard way that the airbags only work in gears 1 and 2, not 3, 4 or 5? Then the "airbags" feature is not complete. That is my argument.
Excellent point. That breaks isolation, and a bug in one application can still cascade problems into other applications.
In particular this is likely to allow security problems in the application to cause malformed data to be entered into the database, thereby affecting other applications.
Typically you should add and subtract in a type-safe manner. Within PostgreSQL, you can simply add an interval of '1 day' and it will correctly give the following day. Any sane language library allows you to add an interval to a date.
What you should not do, is pass garbage to the parser and expect the parser to clean it for you. You also should not start adding to arbitrary digits in the date string and hope for the best. What's "2 2" + "9"? Is it "11 2" or "2 11" or "31" or 31?
My reply was apt. The parent said that there was little reason to switch, I gave some reasons. I stated a fact (that MySQL thinks Feb 31st is a date), which is not bashing. It looks like bashing because it makes MySQL look bad.
I don't have a problem with other databases. The only database that, to me, stands out as particularly bad is MySQL. That's because their marketing deceives many people.
Someone may see: 1. "MySQL supports strict SQL compliance mode" 2. "MySQL is easy to use from the default install" 3. "MySQL is screaming fast" 4. "MySQL has transactions" 5. "MySQL has more applications written for it than PostgreSQL"
But... #1 conflicts with #2 and #5 because strict is off by default, and there are fewer "MySQL Strict Mode" apps than PostgreSQL apps. #2 conflicts with #4 because the default install and CREATE TABLE create MyISAM tables which do not support transactions. #3 conflicts with #4 because the "screaming fast" reputation is from MyISAM tables. InnoDB is somewhat similar in performance to PostgreSQL.
Everything about MySQL pigeonholes you into a subset of the features that MySQL AB advertises, and then makes it as difficult as possible to roam between those features. In MySQL, if you need to change the type of a table, for instance if you want transactions, you can't do that without disrupting running applications. You need to pause and resume all the applications accessing that table.
Compare to PostgreSQL, if you need to, for example, change the disk that a table is stored on (of course PostgreSQL doesn't have different table types), you can make all the necessary DDL modifications in a transaction-safe way, and the application will never know the difference.
I know MySQL has uses. I use it (sparingly). Slashdot uses it, for good reasons I'm sure. But "has it's uses" does not mean "immune from criticism".
MySQL's arguments, like it's features, always seem to be mutually exclusive.
MySQL's benefits: * More Applications * Has strict mode if you need it * Easier to use by default * Speed * ACID
The problems are: * Strict mode is not enabled by default * If strict mode is easier because of all the benefits of data consistency, then MySQL is not easy by default * PostgreSQL has more applications than does "MySQL Strict Mode". * ACID is only on the InnoDB table type, and the highest basic data access speed is on the MyISAM table type
The list goes on. You can argue any one point and say it works just fine, and that you don't care about the other ones.
But PostgreSQL is a whole solution. When they say you have ACID compliance, it doesn't matter what tables you operate on. When they have a reasonably consistent SQL dialect, it can't be configured to be drastically different on a whim, making half the applications (or more) not even work. In short, the features in PostgreSQL don't have long lists of dislaimers and incompatibilities with other features. They just work as advertised.
I would be interested to see some benchmarks to back that up. PostgreSQL has a lot of features that can be used to improve the speed of a query by orders of magnitude.
What if you have a table and you need a functional index on a user defined function? MySQL can't even do that, so it will be forced to scan the whole table. PostgreSQL makes it trivial.
PostgreSQL can also combine indexes into in-memory bitmaps before looking in the table. That means you don't have to make a multi-column index for every combination of attributes you select. This is done automatically by the planner.
When you actually make use of some of the "features that nobody needs" in PostgreSQL, you can see huge performance gains. I'm not sure how it stacks up against Oracle, because they don't let their users publish results.
But yeah, you're right. If you just port some MySQL code to PostgreSQL, the PostgreSQL code will likely not perform as well (unless there are joins where the planner can use some of the features like the bitmap index).
PostgreSQL will always be slower than a MySQL database that uses MyISAM tables.
Not necessarily true. What about when joins are a factor? Or what about when you can use a PostgreSQL feature like a functional index (on a user-defined function) to speed up a query, and that's not even available in MySQL? Or what about when PostgreSQL has more index usage opportunities, like the ability to combine two indexes in an in-memory bitmap before scanning (that means you don't have to make multi-column indexes for every combination of attributes you select, and it organizes the tuples to fetch into sequence for faster reads)? What about the ability to manage a large number of joins with the GEQO (genetic algorithm for determining the optimal join order)?
There are all kinds of opportunities for speeding up queries that don't involve sacrificing consistency.
Then again, MyISAM should not be used for anything more complex or important than storing cooking recipees.
What if you're a German and you store the family beer recipe in a MyISAM table? I'd start looking at a place to live in exile in case the power dies and you lose the recipe. You don't get any more mission-critical than that:)
MySQL has never cared about enforcing database integrity and are just starting to do so.
Yes, the fact is that MySQL is trying to adopt a more PostgreSQL-like philosophy, using their market share and name recognition. In the meantime, the current users are in for a rough ride of backwards-incompatibility.
So, the question is, does MySQL get PostgreSQL's features and philosophy in place before PostgreSQL get's MySQL's market share in place?
I believe you're referring to "max_fsm_pages". That can, and should, be adjusted. If you leave that parameter at a reasonable level, and vacuum at reasonable intervals, it shouldn't be a problem.
For any high performance database task, you shouldn't expect 100% autotuning.
Isn't this fixed in recent versions of MySQL anyways?
In the last thing I installed which is whatever came from the FreeBSD ports collection, it was still a problem. 4.1 I believe.
As MySQL gets a lot of flack for this poor design philosophy*, they have come up with "strict mode" as a solution. That's a configuration option that is more strict about reporting errors. It's a step in the right direction, but that makes it wildly imcompatible with many MySQL applications.
So it's "fixed" in the sense that you can optionally break backwards compatibility to fix it. I haven't heard many reports about people actually trying to use strict mode.
* MySQL has backtracked on design philosophy before. Remember back when an ACID transaction was evil and slow and MySQL would never implement transactions or triggers or anything else?
And what evidence did he have that MySQL users do not want consistency? I know MySQL users who want consistency and type checking, and are impressed when they try PostgreSQL.
It all depends on the situation, but PostgreSQL gives you a lot of options. Pretty much every database needs to have cleaner processes to clean free space.
With PostgreSQL, you can do it manually, or use autovacuum. You can also set the vacuum_cost_delay to change how much it interferes with concurrent access. Whatever works best.
I don't mean to criticize SQLLite, because it's good for many applications. However, some of their benchmarks make no sense in the real world. Also, take caution with anything labeled "async", that means your transactions are not durable! (if you're system crashes, the data can be inconsistent).
Postgres's replication options are niche afterthought hacks.
Kind of like how Firefox, Opera, &etc. are "niche afterthought hacks" on top of Linux? (After all, aren't browsers supposed to be integrated into the OS?)
More accurately, PostgreSQL's amazing extensibility, which was planned since the beginning, allowed it to employ a variety of replication solutions without hacking up the base server. This means that if you need a new replication feature, you don't have to wait for the next release of the entire server, or upgrade anything.
Use autovacuum. The current version has autovacuum built into the backend. How much easier can it get? And it shouldn't interfere to much with concurrent connections.
PostgreSQL is slow.
It gets this reputation if you run a MySQL app on top of PostgreSQL because MySQL does some types of things faster. However, I think you'll find in many cases the application will have superior performance to the MySQL version if you write PostgreSQL specific code in the application's data access layer.
Slashdot Mirror
Now, the reason I wouldn't use PostgreSQL in some instances, PostgreSQL still does not have any clustering features that I am aware of.
.org in slashdot.org, and every other .org or .info).
It sure does:
* Slony-I: master-slave, table-level backup. Works across postgresql versions, which means it's very convenient to use to upgrade. Very good software, well tested in live environments (that's what serves the
* PgPool: Query based replication software and network management software. This can work as multi-master by distributing queries, or work with Slony.
* Also, 8.1 has the very nifty feature called "Two Phase Commit" (a.k.a. 2PC). This allows network management software to synchronously commit on multiple machines to create a multi-master solution.
gives real-world usable examples of each documented function,
If something is lacking in the documentation, please write to the mailing lists. I'd be happy to write a few documentation pages in my spare time. However, what might be obvious to a PostgreSQL person might not be to someone coming from another database background. So, I don't know what about the documentation needs work.
If you really don't care about transactions, in PostgreSQL you can always turn fsync off and put the logs on a RAM disk. That will be fast but unsafe, just like you're talking about.
MS Access.
There are a few things going on. First of all, Access is two things, a frontend and the Jet database engine. The frontend isn't really what we're talking about, because you could hook that up to MS SQL or PostgreSQL if you wanted.
Jet, I don't really know. I've heard with even a few concurrent accesses it slows to a crawl. But also, in the short time I used it, seemed to have sane behavior when I issued SQL commands: errors where I expect, otherwise the expected result. I can't say the same for MySQL.
Microsoft sells Access as what it is: a few users only, small databases. When you start using it for a workgroup in an office of, say, 20 people, Microsoft will happily upgrade you to SQL server without excessive hassle (I've heard some bad stories, but in the simple case an upgrade will be smooth).
So it's hard for me to criticize Jet too much, because it's part of the overall MS solution. Any complaints and the obvious answer would be "you should have that on SQL Server". Sort of like if you download an application and select the "store this in a flat file" option instead of entering your JDBC connection info.
That being said, I fortunately have not had to work much with Access, so maybe I dodged a few bullets without knowing it.
A lot of benchmarks are published using MyISAM, and a lot of anecdotal evidence that's passed around refers to MyISAM, because it's the default. When people hear about these results, they assume that all of MySQL is fast. When people hear about transactions, they assume all of MySQL has transactions.
I have not seen anything that demonstrates that InnoDB is faster than PostgreSQL in the general case. In fact, InnoDB employs a lot of the same design as PostgreSQL tables. InnoDB uses MVCC-like technology, and a VACUUM-like garbage collection process called "purge". For most types of operations, InnoDB will be similar in performance to PostgreSQL.
I'm not saying that InnoDB is slow. I'm saying that MySQL AB uses deceptive marketing. They are very successful at marketing by using MyISAM as the default, so that anecdotal evidence about speed are always very positive toward MySQL, and then when someone wants transactions then then MySQL must pull the switcharoo on the table type.
It's like you walk into a store because they advertise one price and it's cheaper than the competition. Then you get there and the product doesn't come with a power adapter, so you have to fork over an extra $5. By the time you leave, the price was the same.
You make a good point. As with anything, it depends a lot on the situation. If that works for you, and you control the entire code base, you're in good shape. Frameworks can help prevent inconsistent database state. And there is a certain redundancy to implementing the check in the database. However, note that since PostgreSQL has already written a date type, and you already declared your column as date in either database, it's no additional work to use, and it's not like it's a performance penalty.
Also, consistency checking can still be helpful. If the coder is slightly lazy for a moment and during testing you get inconsistent data in the database, it's really hard to extract that data out and get it back to a consistent state. If you have good development practices, this may never happen. But it's very annoying when it does happen.
Code can be stopped, fixed, and restarted, but the data in the database represents long term application state, and if that gets inconsistent it can do a lot of damage.
That being said, I don't claim to always program every business rule into the database for 100% consistency. But doing the easy stuff can go a long way: check constraints, a trigger or two, foreign keys, and type checking (which is generally not any additional work).
A lot of people use PHP/MySQL. One PHP page inserts bad data, another tries to access that bad data. It might not be multiple applications, but it's distinct operations within one application. It's a lot easier to debug if it throws an error on the page that tries to insert the bad data, because then you know exactly what caused the error. If you're just staring at bad data in the database already, you have no way to know where it came from.
If a programmer's code was tight then that person wouldn't have this problem. MySQL does just what is supposed to do, which is store data.
What you're saying is that every application should have to trust not just the database and DBAs, but every other application attached to the database.
That makes it hell to find bugs that insert bad data. In PostgreSQL, you can set it up so that the application which has the bug gets the error. In MySQL, the bug might not be discovered until another application gets confused by the bad data. Even if the second application properly detects the error, it has no information to help you find the source of the bug.
Interesting information, but just because the German High Court says that February 30th is a date doesn't mean it is.
If you are a bank there are probably lots of date-oriented laws by which you must abide. If a bank needs a special date type where every month is 30 days, they can make a custom type in PostgreSQL that handles it according to local laws.
By the way, if every year has 360 days, isn't there drift due to leap years?
No, my complaint is that the features are advertised as being present, yet each feature is highly conditional. It's deceptive.
PostgreSQL is complete. If they advertise a feature, it works fluidly in conjunction with all the other features they advertise.
What if you bought a car? "It is fast" and "it has airbags". Well, what if you find out the hard way that the airbags only work in gears 1 and 2, not 3, 4 or 5? Then the "airbags" feature is not complete. That is my argument.
Excellent point. That breaks isolation, and a bug in one application can still cascade problems into other applications.
In particular this is likely to allow security problems in the application to cause malformed data to be entered into the database, thereby affecting other applications.
Typically you should add and subtract in a type-safe manner. Within PostgreSQL, you can simply add an interval of '1 day' and it will correctly give the following day. Any sane language library allows you to add an interval to a date.
What you should not do, is pass garbage to the parser and expect the parser to clean it for you. You also should not start adding to arbitrary digits in the date string and hope for the best. What's "2 2" + "9"? Is it "11 2" or "2 11" or "31" or 31?
My reply was apt. The parent said that there was little reason to switch, I gave some reasons. I stated a fact (that MySQL thinks Feb 31st is a date), which is not bashing. It looks like bashing because it makes MySQL look bad.
I don't have a problem with other databases. The only database that, to me, stands out as particularly bad is MySQL. That's because their marketing deceives many people.
Someone may see:
1. "MySQL supports strict SQL compliance mode"
2. "MySQL is easy to use from the default install"
3. "MySQL is screaming fast"
4. "MySQL has transactions"
5. "MySQL has more applications written for it than PostgreSQL"
But...
#1 conflicts with #2 and #5 because strict is off by default, and there are fewer "MySQL Strict Mode" apps than PostgreSQL apps.
#2 conflicts with #4 because the default install and CREATE TABLE create MyISAM tables which do not support transactions.
#3 conflicts with #4 because the "screaming fast" reputation is from MyISAM tables. InnoDB is somewhat similar in performance to PostgreSQL.
Everything about MySQL pigeonholes you into a subset of the features that MySQL AB advertises, and then makes it as difficult as possible to roam between those features. In MySQL, if you need to change the type of a table, for instance if you want transactions, you can't do that without disrupting running applications. You need to pause and resume all the applications accessing that table.
Compare to PostgreSQL, if you need to, for example, change the disk that a table is stored on (of course PostgreSQL doesn't have different table types), you can make all the necessary DDL modifications in a transaction-safe way, and the application will never know the difference.
I know MySQL has uses. I use it (sparingly). Slashdot uses it, for good reasons I'm sure. But "has it's uses" does not mean "immune from criticism".
MySQL's arguments, like it's features, always seem to be mutually exclusive.
MySQL's benefits:
* More Applications
* Has strict mode if you need it
* Easier to use by default
* Speed
* ACID
The problems are:
* Strict mode is not enabled by default
* If strict mode is easier because of all the benefits of data consistency, then MySQL is not easy by default
* PostgreSQL has more applications than does "MySQL Strict Mode".
* ACID is only on the InnoDB table type, and the highest basic data access speed is on the MyISAM table type
The list goes on. You can argue any one point and say it works just fine, and that you don't care about the other ones.
But PostgreSQL is a whole solution. When they say you have ACID compliance, it doesn't matter what tables you operate on. When they have a reasonably consistent SQL dialect, it can't be configured to be drastically different on a whim, making half the applications (or more) not even work. In short, the features in PostgreSQL don't have long lists of dislaimers and incompatibilities with other features. They just work as advertised.
I would be interested to see some benchmarks to back that up. PostgreSQL has a lot of features that can be used to improve the speed of a query by orders of magnitude.
What if you have a table and you need a functional index on a user defined function? MySQL can't even do that, so it will be forced to scan the whole table. PostgreSQL makes it trivial.
PostgreSQL can also combine indexes into in-memory bitmaps before looking in the table. That means you don't have to make a multi-column index for every combination of attributes you select. This is done automatically by the planner.
When you actually make use of some of the "features that nobody needs" in PostgreSQL, you can see huge performance gains. I'm not sure how it stacks up against Oracle, because they don't let their users publish results.
But yeah, you're right. If you just port some MySQL code to PostgreSQL, the PostgreSQL code will likely not perform as well (unless there are joins where the planner can use some of the features like the bitmap index).
PostgreSQL will always be slower than a MySQL database that uses MyISAM tables.
:)
Not necessarily true. What about when joins are a factor? Or what about when you can use a PostgreSQL feature like a functional index (on a user-defined function) to speed up a query, and that's not even available in MySQL? Or what about when PostgreSQL has more index usage opportunities, like the ability to combine two indexes in an in-memory bitmap before scanning (that means you don't have to make multi-column indexes for every combination of attributes you select, and it organizes the tuples to fetch into sequence for faster reads)? What about the ability to manage a large number of joins with the GEQO (genetic algorithm for determining the optimal join order)?
There are all kinds of opportunities for speeding up queries that don't involve sacrificing consistency.
Then again, MyISAM should not be used for anything more complex or important than storing cooking recipees.
What if you're a German and you store the family beer recipe in a MyISAM table? I'd start looking at a place to live in exile in case the power dies and you lose the recipe. You don't get any more mission-critical than that
MySQL has never cared about enforcing database integrity and are just starting to do so.
Yes, the fact is that MySQL is trying to adopt a more PostgreSQL-like philosophy, using their market share and name recognition. In the meantime, the current users are in for a rough ride of backwards-incompatibility.
So, the question is, does MySQL get PostgreSQL's features and philosophy in place before PostgreSQL get's MySQL's market share in place?
I believe you're referring to "max_fsm_pages". That can, and should, be adjusted. If you leave that parameter at a reasonable level, and vacuum at reasonable intervals, it shouldn't be a problem.
For any high performance database task, you shouldn't expect 100% autotuning.
Isn't this fixed in recent versions of MySQL anyways?
In the last thing I installed which is whatever came from the FreeBSD ports collection, it was still a problem. 4.1 I believe.
As MySQL gets a lot of flack for this poor design philosophy*, they have come up with "strict mode" as a solution. That's a configuration option that is more strict about reporting errors. It's a step in the right direction, but that makes it wildly imcompatible with many MySQL applications.
So it's "fixed" in the sense that you can optionally break backwards compatibility to fix it. I haven't heard many reports about people actually trying to use strict mode.
* MySQL has backtracked on design philosophy before. Remember back when an ACID transaction was evil and slow and MySQL would never implement transactions or triggers or anything else?
And what evidence did he have that MySQL users do not want consistency? I know MySQL users who want consistency and type checking, and are impressed when they try PostgreSQL.
It all depends on the situation, but PostgreSQL gives you a lot of options. Pretty much every database needs to have cleaner processes to clean free space.
With PostgreSQL, you can do it manually, or use autovacuum. You can also set the vacuum_cost_delay to change how much it interferes with concurrent access. Whatever works best.
I don't mean to criticize SQLLite, because it's good for many applications. However, some of their benchmarks make no sense in the real world. Also, take caution with anything labeled "async", that means your transactions are not durable! (if you're system crashes, the data can be inconsistent).
"Building a Brighter LAMP: Linux Apache Middleware PostgreSQL"
PostgreSQL 7 was released in the year 2000. It's come a long way in 6 years (and that's a huge understatement), I recommend you give it another try.
Note: A lot of the corporate-funded developments came after that time.
Postgres's replication options are niche afterthought hacks.
Kind of like how Firefox, Opera, &etc. are "niche afterthought hacks" on top of Linux? (After all, aren't browsers supposed to be integrated into the OS?)
More accurately, PostgreSQL's amazing extensibility, which was planned since the beginning, allowed it to employ a variety of replication solutions without hacking up the base server. This means that if you need a new replication feature, you don't have to wait for the next release of the entire server, or upgrade anything.
VACUUM is a pain.
Use autovacuum. The current version has autovacuum built into the backend. How much easier can it get? And it shouldn't interfere to much with concurrent connections.
PostgreSQL is slow.
It gets this reputation if you run a MySQL app on top of PostgreSQL because MySQL does some types of things faster. However, I think you'll find in many cases the application will have superior performance to the MySQL version if you write PostgreSQL specific code in the application's data access layer.