Slashdot Mirror

There's a list of PostgreSQL hosting companies available. Last time I was picking one A2 and hub.org made my short list; there are plenty of others too.

It's called PostgreSQL. It's fast, what's even more important, it's correct and it's tried and tested. Get it here.

What are the compelling differences?

Security. Scalability. And recently, raw performance with more much more room through to exist. Superior query plan general for non-trivial queries; which also goes to the first three items listed. Extensibility such that MySQL can't even be compared. Geospacial capabilities with indicies + ACID. PLs for stored procedures and a multitude of choices and capabilities. Real life deployments where ACID accounts; compared to MySQL where people generally use it as a large, non-ACID storage retrieval system where data inconsistencies are typically also allowed, rather than an ACID-compliant RDBMS.

In all seriousness, for the vast, vast majority of users, the only literal advantage MySQL has over PostgreSQL is DB upgrade paths, and even then, huge strides are being made on the PostgreSQL front. See PG Migrator. Huge improvements have been made since the 7.x days. See the docs for more info.

What are you using to cluster Postgres? I have looked at a couple of options here but didn't see an open source solution that was current and able to handle multi-master synchronous replication with some sort of automatic failover.

Thanks for your response!

http://wiki.postgresql.org/wiki/Postgres-2

http://wiki.postgresql.org/images/1/1a/Postgres-2_Write-Scalable_Cluster.pdf

http://wiki.postgresql.org/wiki/Postgres-2

http://wiki.postgresql.org/images/1/1a/Postgres-2_Write-Scalable_Cluster.pdf

PostgreSQL at least, and probably other databases, has a generic "key-value store" data type: http://www.postgresql.org/docs/8.3/interactive/datatype.html. With it, rows can contain some strictly-typed data (such as IDs, types, other metadata) and also contain a field (or many fields) which store all other loosely-typed data. And since it's PostgreSQL, all data is safe, can be replicated, you can have complex indexes, full text search, etc.

This device could drive large numbers of companies out of business, companies who invested a lot of money in those businesses.

This is a terrible example, because this *particular* example relieves the need for anyone to run a company, work at a company, or buy anything from a company. Food, clothing, people, pets, shelter, medicine... anything could be duplicated. No one would need money (and if they did, they could duplicate it.)

Such a machine would reset our entire society -- and it should.

The only reason anyone needs to make money is because money is the machine of "matter duplication", speaking very loosely; it allows you to get "your copy" of the food, property, etc. The only reason this in itself is the process is because things are, relatively speaking, scarce and expensive. Your machine would eliminate both issues.

The potential for a literal utopia would loom. Most likely to be destroyed immediately by massive duplication of weapons, but still, the potential would have been there.

The actual issue with intangible property is that by taking it and not complying with the terms of the rights owners, in the process reducing or eliminating return from said property, the motivation for the rights owners to continue to produce these things for society is damaged, and consequently, society is damaged (and will inevitably develop a means of recourse.) All the excuses in the world cannot get around this; and that is why it is wrong. It does real harm. Directly to the property owner, and indirectly, but very broadly, to the rest of society.

If you (not you in particular, but those reading this that think taking software without the rights/property owner's stipulated recompense is somehow ok) want free software, find some software that someone offers for free, because supporting themselves isn't the motive.

There's plenty of it, too. Like my free tiny database software, here. Or this massive, feature-heavy - yet still free - database package, here.

But if you elect to take property / rights that is offered in exchange for some fee or service you decline to provide, you're an antisocial, simple-minded scumbag. It's exactly as simple as that. And it doesn't matter a flying fuck if the software has a free variant or not, or if you "need" it, or if you "want" it.

People who create - music, art, software - are of much greater value to society than people who steal, and they always will be. And society will always come down on their side for that very reason. And that's just how it should be.

I'd go so far as to say that in a society where the above machine existed, people who create new things would be the most respected members of all. Because duplication is not invention, and invention can, and often does, improve everyone's lot. And what would that get them? Attention, appreciation, and to some degree, power - because people will wish to please them. They'd be rock stars.

Because they wouldn't have survived very long. And none of us would be using MySQL. Don't you think that's self-defeating?

When you say survived very long; do you mean in economic terms, Bruce?

There are a number of large organisations of various kinds using PostgreSQL. They also had a new version released earlier this month, too...so apparently finding the resources to continue its' development isn't a problem for them.

Although I'm aware that it generally isn't considered socially acceptable to discuss this in Linux-related circles, it is actually possible to make money using BSD licensed software, you know. It seems to be working fairly well for Apple. ;)

The acquisition of MySQL by Oracle will be a major setback to the development of a FLOSS database platform, potentially alienating and dispersing MySQL's core community of developers. It could take several years before another database platform could rival the progress and opportunities now available to MySQL, because it will take time before any of them attract and cultivate a large enough team of developers and achieve a similar customer base.

I will link to PostgreSQL again, here, and probably again get modded down to -1 Redundant or Overrated, by GPL fanatics who don't want anyone to know that Postgres exists, because of the fact that it uses the BSD license.

Of course, given the way I've written the above, they will probably try and perhaps use that as an excuse to appear more legitimate, by down-modding this to -1 Troll or Flamebait, instead.

Wow, not just misinformed, but proud of it too!

I started using pg about 10 years ago on version 6.5.2, released 1999-09-15. Here's a list of fixes that 6.5.2 provided:

http://www.postgresql.org/docs/8.4/static/release-6-5-2.html (I count 23). note the previous version, 6.5.1 was released 1999-07-15. So that's 23 changes in two months. 10 years ago.

7.0.0 was released on 200-05-08, or about 8 months later, and here's the list of changes / updates to that:
http://www.postgresql.org/docs/8.4/static/release-7-0.html (I count 4 major architectural changes and about 275 or so minor changes)

Yeah, no development on pgsql 10 years ago. You might try fact checking your shit next time.

Wow, not just misinformed, but proud of it too!

I started using pg about 10 years ago on version 6.5.2, released 1999-09-15. Here's a list of fixes that 6.5.2 provided:

http://www.postgresql.org/docs/8.4/static/release-6-5-2.html (I count 23). note the previous version, 6.5.1 was released 1999-07-15. So that's 23 changes in two months. 10 years ago.

7.0.0 was released on 200-05-08, or about 8 months later, and here's the list of changes / updates to that:
http://www.postgresql.org/docs/8.4/static/release-7-0.html (I count 4 major architectural changes and about 275 or so minor changes)

Yeah, no development on pgsql 10 years ago. You might try fact checking your shit next time.

I invite people to investigate PostgreSQL.

I was going to outline a list of its' features, but said list is very large, so I'll paste the address instead, so you can go and check it out for yourselves:- http://www.postgresql.org/about/featurematrix

Is the open source solution close enough to the needs of the Ontario government that, as the article alleges, all you need to do is buy some servers and set it up and there are negligible other costs? I seriously doubt it. I would be willing to bet heavily against it. Anyone who thinks otherwise probably hasn't spent much time developing software for government.

I haven't, no...but what are said needs?

I'm assuming that the main component of a record system is going to be a database. You'll also need a usable system and interface for entering and retrieving said records into the DB. You're also going to want to do SQL dumps and periodic offsite backups, so that if anything goes wrong, you can get the data back.

Of course, it will also be very important to ensure that the operating system the database is hosted on, is as robust as possible, to minimise the possibility of crashes; as well as a strong filesystem for times when you need to make a lot of queries at once. Even though that system is meant for servers, you can still make it user friendly for your administrative staff as well, if you need to.

If you're going to want the records accessible from outside the hospital, you'll probably also want to make sure that they are protected by a couple of very secure firewalls, as well, since it could potentially mean the loss of someone's life if they get cracked.

Finally, they will need to make sure that whoever puts the network together does so according to sound administration principles, as well.

ext3 is also a journaling file system. Perhaps you meant ext2?

I'm not sure you want to run fsck on an unclean shutdown on your nice big database partition either. Maybe using a journaled file system isn't such a bad idea. Also, it can be much faster for certain workloads:

http://en.oreilly.com/oscon2009/public/schedule/detail/8432
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide

Note that while sequential writes could be much slower with journaled file systems, random writes were typically much faster. This is what one would expect, given how journaled file systems work.

"What the hell is going on at the Oracle website, for example?"

Here is a guess: The technically knowledgeable people are paid to develop products. Management considers them too expensive to document what they do.

Instead, Oracle management hires marketing people to supervise the development of the web site and documentation. The marketing people have no interest in technology -- none. They are bored with their jobs. They secretly think that technically knowledgeable people are inferior. They do, however, learn some buzz-words so that they can pretend that they understand.

The marketing people don't believe technical communication is important. They have seen numerous examples of people being able to use Oracle products even though the documentation is poor. The web site and product manuals are either almost useless or written for people who already understand the products. Editing for clarity is very limited.

The writers are hired as consultants. When a writer doesn't understand something, he or she just doesn't document it, or gives a limited explanation.

Oracle web site page chosen completely at random: Oracle Database Management Packs.

Quote (Title): "Get Maximum Performance With ROI of 100%" Translation: Meaningless.

Quote (First sentence): "Oracle provides an integrated management solution for managing Oracle database with a unique top-down application management approach." Translation: Meaningless. A "management solution for managing a management approach"? But... It's "integrated"! And, notice the grammatical error. It should be "managing Oracle databases".

When I see trash like that I feel sad. I sometimes think I should contact the board of directors and ask to be CEO, so that the company will have adult supervision. I'm being sarcastic, but I really do feel genuinely sad about corporate self-defeat.

More sarcasm: Will the combination of Oracle and Sun be called "Snoracle"?

Seriously: Will PostgreSQL eventually be the world's most popular database software? To me, those two quotes from the Oracle web site are a very effective ad for PostgreSQL.

It's PostgreSQL... but I sympathize with the mixed case confusion and refer you to this Postgres vs PostgreSQL permathread.

It's PostgreSQL... but I sympathize with the mixed case confusion and refer you to this Postgres vs PostgreSQL permathread.

You cannot easily add new fields to a table

Some database systems make this easy.

Migrating large amounts of relational data to a new structure takes a very very long time.

That's true for any large amount of data. Relational data tends to be much more flexible, so this is less important than in, say, a hierarchical database where reorganization is not only incredibly expensive, but may be a prerequisite for even passable performance of some queries.

It's difficult to maintain the data integrity... and have acceptable performance

Again, not specific to relational database systems. It's much more difficult and expensive to maintain data integrity in a hierarchical system unless the constraint and the hierarchy are one and the same.

Then design queries to answer questions such as

Those questions can be answered quite easily using either a materialized path representation (using something like ltree, or WITH ... RECURSIVE.

Materialized path would be an efficient way to answer those questions. However, if you try to use some graph or hierarchical database system, then that will be the only way you can efficiently access your data; with a SQL system, it's easier to allow the user to ask a variety of very different questions without bias toward any one particular type of question.

Consider storing something like an iPod. You can store it at: /hardware/apple/ipod; or /apple/hardware/ipod

The former makes it very hard to find all the products that are made by apple (because you have to search other higher-level categories, like software, etc). The latter makes it very hard to find all hardware products for the same reason (you have to search /ibm/hardware, /microsoft/hardware, etc).

In a relational system, you'd just say something like "where vendor=apple" or "where category=hardware". The relational organization more closely resembles reality because the hierarchy is 100% artificial.

I'm sure you can always find a particular set of queries that run faster on your favorite hierarchical or graph database system, but that's not the point. The point is that it biases the queries you ask (both in terms of ease and also efficiency) so heavily that the mixed queries found in most real businesses will cause problems for a hierarchical/graph databases system.

SQL can't handle most datastructures and complex relations, only very simple one dimensional ones

That shows ignorance of the relational model. Relations are n-dimensional, where n is the number of attributes.

Then design queries to answer questions such as

Those questions can be answered quite easily using either a materialized path representation (using something like ltree, or WITH ... RECURSIVE.

Materialized path would be an efficient way to answer those questions. However, if you try to use some graph or hierarchical database system, then that will be the only way you can efficiently access your data; with a SQL system, it's easier to allow the user to ask a variety of very different questions without bias toward any one particular type of question.

Consider storing something like an iPod. You can store it at: /hardware/apple/ipod; or /apple/hardware/ipod

The former makes it very hard to find all the products that are made by apple (because you have to search other higher-level categories, like software, etc). The latter makes it very hard to find all hardware products for the same reason (you have to search /ibm/hardware, /microsoft/hardware, etc).

In a relational system, you'd just say something like "where vendor=apple" or "where category=hardware". The relational organization more closely resembles reality because the hierarchy is 100% artificial.

I'm sure you can always find a particular set of queries that run faster on your favorite hierarchical or graph database system, but that's not the point. The point is that it biases the queries you ask (both in terms of ease and also efficiency) so heavily that the mixed queries found in most real businesses will cause problems for a hierarchical/graph databases system.

SQL can't handle most datastructures and complex relations, only very simple one dimensional ones

That shows ignorance of the relational model. Relations are n-dimensional, where n is the number of attributes.

I use PostgreSQL daily and I love it. The window functions are an enormous boon! It's still the best.

We need some distribution happening a la Netezza, Greenplum, etc:

• pgpool-II: old Oracle-style partitioning on a single column with fixed partition values
• GridSQL: stuck in 1.1beta for a long time but promises Teradata-style shared-nothing parallelism

Anyone know better?

Thats perfectly fine and well, but can you put two different schemas in two different boxes? no, you can't.

Depending on what you're trying to achieve with that, you could store the data with partitioning and network file systems (not that I'd risk my data that way). But can you actually do hr.employee.id=job.task.employee on mysql when hr and job are "databases" on different servers?

Anyway, if you really have an external database (that may be somewhere entirely different) there's DBlink and its friend DBI-Link.

git repo
Design spec

This is the feature that didn't quite make it in 8.4. Look at how much effort and research went into the design. This isn't a situation where someone threw some code together; this is real design and real code by a highly reputable hacker, that answered feedback from other highly reputable hackers.

The only reason this didn't make it is that PostgreSQL has a reputation for getting things right (really right), and that's more important than one feature.

But try it out. If the code hasn't rotted too much, it should work fine.

git repo
Design spec

This is the feature that didn't quite make it in 8.4. Look at how much effort and research went into the design. This isn't a situation where someone threw some code together; this is real design and real code by a highly reputable hacker, that answered feedback from other highly reputable hackers.

The only reason this didn't make it is that PostgreSQL has a reputation for getting things right (really right), and that's more important than one feature.

But try it out. If the code hasn't rotted too much, it should work fine.

There aren't as many hosting companies that support PostgreSQL, but they are out there. http://www.postgresql.org/support/professional_hosting has a list.

I think the #1 surprise to people coming from MySQL is that PostgreSQL is more likely to throw errors for poorly-written queries or constraint violations.

Download the 8.4 beta, install it, run an application, and if you see any more surprises or gotchas, beta time is a great time to point them out ;)

That's weird,
Here http://www.postgresql.org/about/users Postgres claims Apple as a featured user.

MySQL's documentation is nowhere near as good as Postgres and when I found out this little tidbit about Postgres, I was sold:

http://www.postgresql.org/docs/8.3/static/datatype-character.html

In particular:

"Tip: There are no performance differences between these three types, apart from increased storage size when using the blank-padded type, and a few extra cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead."

There is more to learn when using Postgres, but not too much just to get up and running. I managed to get it running with an ORM that had been using MySQL in a few hours. The docs are really good too. Oh yeah, and my favorite animal is an elephant.

I've heard the arguments that postgres is as easy as MySQL, and they're bullshit.

Lets see:

Postgres has no good GUI applications that can compare with MySQL's

Why you need more than one is beyond me. Isn't Pgadmin enough?

their command line application is just as good in its own way

Well, ok. Whatever 'in its own way' means.

and the market share that ensures you need to google multiple times to find the info you're looking for.

Postgres has some of the best documentation of any open source project I've seen. Sure, MySQL is good as well, but lets not spread bullshit here.

Installing postgres is also a nightmare compared to MySQL.

You mean in a download-the-msi-and-double-click-on-it way, or the apt-get-install-it way?

To sum up: free > $millions, easy > full-featured (in many circumstances).

Well, it's fully-featured, but not necessarily all of those features at the same time. Try doing full-text indexing on a database with foreign-keys on it in MySQL sometime.

Many of us MySQL users see your Postgres question the same way: why use Postgres?

Because MyISAM, which is what most MySQL users use, is not fucking ACID compliant.

Take a look at the potential problems. Take a look at recommended use cases: "Tables which contain read-only data, throw-away data, data which can be quickly re-generated." Are you bloody kidding me!?

I can't believe my eyes when I read questions (or posts) such as the above. Because it betrays your huge ignorance. Every man and his dog has heard of MySQL and is probably using it, true. But it's also true that most of them have no bloody idea of what ACID is or why it's desirable, or that MySQL with its MyISAM tables goes completely happy-go-lucky on the whole concept. These are the same people who probably don't bother using foreign keys, or have never even heard of transactions, or can't think why they'd need them.

Sure, MySQL offers InnoDB, which is supposed to rectify those issues. But how does it go about it, may I ask? Why, take a looksy. It's an entire bloody SECTION of the manual, which goes to great lengths to explain all kinds of issues and exceptions to the rules and whatnot. Summary: "It locks rows like this, except if it's a full moon then you have to blink your left eye every five seconds, and if you're doing a particular SELECT you need to stand on one leg, except on Fridays when it's the right leg."

Now compare with the Postgres manual page describing their ACID implementation. It's a couple of pages, keeping things clear and simple, so that anybody can understand them.

Not to forget that if you want InnoDB you give up full text search capabilities. And you ask why we should use Postgres? Really?

MySQL has lowered the bar for complexity of use. But in doing so it has facilitated DB access to a whole bunch of people who don't have any idea what they're doing, or don't really care about data integrity. It's fast and it works most of the time so it's alright, yes? Yes, granted, nobody will care much if your personal blog goes tits up because of MySQL. But I expect people will care if a database in which data actually counts for something has problems. And in such cases I expect people will want a real database.

Slony-I is asynchronous. Read postgres' excellent documentation for some other possibilities.

You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.

visit http://www.postgresql.org/

You'll be glad to hear about the autovacuum built into PostgreSQL versions 8.1+. (Ok, so it's not on by default yet. One configuration switch.)

I could give you the good reasons for having VACUUM run separately, (Actually, it's often easier to know from outside when your database is going to be busy...), but in general I agree having to run VACUUM was a pain. I'm glad it's no longer needed.

This is one major reason why I refuse to use PostgreSQL: VACUUME for the fail.

Why the hell do we have to hand hold PostgreSQL to get it to clean up after its self? MySQL has no problem doing it on its own nor does any other databases that I know of require such an operation. Its also quite lame to run a dedicated daemon to monitor and tell PostgreSQL to clean up its mess. Another thing which was a past problem was the user permissions were just terribly implemented making it a complete joke to use for multi-user environments. Now it does appear that was resolved.

The reason why I really have such a huge problem with VACUUM is that there is just no way in hell that a user program could ever know a good time to issue the cleaning procedure, that should be the database's job, not the user program period because it won't ever know about all the transactions going on and so forth. Imagine if the Linux kernel required root to issue some commands to have the kernel clean up after cache handling messes every once in a while to ensure continuing operation of the operating system and then a couple years later the devs figured creating a dedicated daemon to automate the command issuing tasks would be sufficient... it just doesn't make sense.

This is one major reason why I refuse to use PostgreSQL: VACUUME for the fail.

Why the hell do we have to hand hold PostgreSQL to get it to clean up after its self? MySQL has no problem doing it on its own nor does any other databases that I know of require such an operation. Its also quite lame to run a dedicated daemon to monitor and tell PostgreSQL to clean up its mess. Another thing which was a past problem was the user permissions were just terribly implemented making it a complete joke to use for multi-user environments. Now it does appear that was resolved.

The reason why I really have such a huge problem with VACUUM is that there is just no way in hell that a user program could ever know a good time to issue the cleaning procedure, that should be the database's job, not the user program period because it won't ever know about all the transactions going on and so forth. Imagine if the Linux kernel required root to issue some commands to have the kernel clean up after cache handling messes every once in a while to ensure continuing operation of the operating system and then a couple years later the devs figured creating a dedicated daemon to automate the command issuing tasks would be sufficient... it just doesn't make sense.

These little puppies, i.e. recursive queries, look pretty cool too. Sounds like a good tool for threaded comment systems or finding related items in a table:

Recursive queries are typically used to deal with hierarchical or tree-structured data. A useful example is this query to find all the direct and indirect sub-parts of a product, given only a table that shows immediate inclusions:

WITH RECURSIVE included_parts(sub_part, part, quantity) AS (
        SELECT sub_part, part, quantity FROM parts WHERE part = 'our_product'
    UNION ALL
        SELECT p.sub_part, p.part, p.quantity
        FROM included_parts pr, parts p
        WHERE p.part = pr.sub_part
    )
SELECT sub_part, SUM(quantity) as total_quantity
FROM included_parts
GROUP BY sub_part

... It will take a while to wrap my brain around this new concept though. That doesn't look like a normal query I'm used to reading!

They'll get replication some day soon. But there is a lot of cool, very useful stuff with every new release. I usually feel like kid in a candy store wondering what's new that I can exploit.

...since that's that database on which Greenplum is based. PostgreSQL 8.4 is coming out soon and looks like it's got a lot of improvements. Too bad replication didn't make it in... hopefully in 8.5.

One of the improvements that looks good is the parallelized restore; RubyForge's upgrade from PostgreSQL 8.2 to 8.3 took 30 minutes to restore the db and it seems like this feature will speed that up considerably.

Get the improved code here.

Well, I supposed they could use PostgreSQL. It wouldn't cost them a penny.

:)

They should have instead invested in making PostgreSQL better, at least developing better replication and clustering.

And settling on a sensible case sensitivity methodology that empowers developers rather than hamstrings them.

I refuse to use the new name PostgreSQL
which is a cheap cop out and attempt to leverage
on the success of MySQL by copying the idea of
the name

The project changed the name to PostgreSQL in 1996:
http://www.postgresql.org/docs/8.3/static/history.html

# MySQL was first released internally on 23 May 1995
# Windows version was released on 8 January 1998 for Windows 95 and NT

-- http://en.wikipedia.org/wiki/MySQL

I doubt that the internally-released version of MySQL on non-windows platforms was so amazingly successful that PostgreSQL felt a need to copy the name.

More likely, it's because PostgreSQL just started supporting SQL, and they wanted the name to appear for anyone searching for a SQL DBMS by typing in "SQL".

http://www.postgresql.org/

Just saying.

So let's restrict our domain a bit for a moment, say to websites. Google uses MySQL for some of their databases. Yahoo! uses MySQL for some of their databases. So do YouTube, Facebook, Wikipedia, and Baidu. That's six of the top ten websites. I couldn't quickly find info on blogger.com or MySpace (too many hits to blogs hosted there!), and presumably live.com and msn.com use MSSQL. That covers all of the Alexa top ten websites. In other words, every top ten website that I was able to find info on uses MySQL, unless it's Microsoft-owned (I didn't even bother checking those).

So tell me: if pgsql is so superior for all purposes, why aren't these places using it instead? Are any of the ten using it at all? What's the biggest website you can find that makes serious use of PostgreSQL? You can't claim that application compatibility or hosting availability are relevant to sites that write their own software and run their own server farms.

I've seen a lot of claims about how much better pgsql is, but somehow big websites aren't using it. Maybe it's more popular in non-web settings? I'm a web developer, so that's what I focus on.

Or maybe, just maybe, pgsql is actually worse than MySQL in some ways that a majority of the top websites have spotted. Just saying.

Or you could have told PostgreSQL to do a case-insensitive search on that SQL statement.

See [NOVICE] Case Insensitive Searching?.

There are a lot of knobs to turn. They are somewhat well-documented knobs, but knobs none the less. MySQL ships with like four sample configurations.

That said, the best solution would be to make it self-opimizing. It already tries to self-optimize its query plans (i.e.: "We aren't gonna support hints on indexes... if the query planner needs hints, the query planner is broken"). It could do something similar with its configuration. But honestly, that would take development time away from more important things like materialized views or WITH queries. I'd much rather have stuff like that.

By the way, you don't have to edit the config file by hand, you can actually edit it from the comfort of your desktop in PgAdmin and even trigger a reload of the file.

There are a lot of knobs to turn. They are somewhat well-documented knobs, but knobs none the less. MySQL ships with like four sample configurations.

That said, the best solution would be to make it self-opimizing. It already tries to self-optimize its query plans (i.e.: "We aren't gonna support hints on indexes... if the query planner needs hints, the query planner is broken"). It could do something similar with its configuration. But honestly, that would take development time away from more important things like materialized views or WITH queries. I'd much rather have stuff like that.

By the way, you don't have to edit the config file by hand, you can actually edit it from the comfort of your desktop in PgAdmin and even trigger a reload of the file.

Are you kidding? PG has incredible docs.

Go to their site (http://www.postgresql.org) and click "Documentation." Heck, I'll do it for you: http://www.postgresql.org/docs/

Witness online documentation (with and without comments!) for the last FIVE server versions. Start poking around in that documentation and it doesn't take long to realize that documentation is far from "lacking."

Early on, PostgreSQL focused on complete implementation and correct behavior over speed, then worried about adding speed later. MySQL focused on speed, and worried over correctness and completeness later. Since then, PostgreSQL has sped up a lot, and MySQL has shaped up in implementation completeness. But it won't surprise me if PostgreSQL still has a few extra features.

This comparison of PostgreSQL vs MySQL is on PostgreSQL's wiki but it seems very fair.

The most interesting bit is this:

It is worth observing that the database engine is part of the core of PostgreSQL, whereas InnoDB is a dual-licensed product presently licensed from Oracle Corporation. It is uncertain how Oracle may alter InnoDB in the future as they act in competition with MySQL AB, whereas PostgreSQL has no such conflict of interests. MySQL AB has been working on a new database engine core called Falcon in order to free themselves from this situation, but historically developing a database core engine that is both fast and reliable has required many years of work and testing before a mature product suitable for production use is available. Initial benchmarks suggest Falcon has plenty of rough edges that need to be addressed.

The forking of MySQL is going to split resources and creating that replacement for InnoDB may take longer.

The Oracle pl/SQL -> PostgreSQL pl/pgSQL link you suggested was from PostgreSQL 7.1, pretty ancient at this point. PostgreSQL 8.3 Porting from Oracle is a current resource.

The pages that come up for "mysql.com" are what I consider to be the "official" version of MySQL.

I didn't even realize the other pages were out there until this article was posted and I started reading the comments.

Not that it matters much -- I'm an http://www.postgresql.org/ fan myself.