Last place I worked we had two monitors for every developer, and we had about 40 developers. Place I work now has 4 developers, and 3 have 2 monitors and 1 has 3 monitors. The one thing we found in both places is that older Nvidia cards work best. 7800 series, stuff like that. Get the latest cards and you'll pull your hair out trying to get them to work.

Yep, but ask on slashdot and you'll find out you and I and other pgsql users are the "fanbois". urg.

Note that there are plenty of solid reliable replication engines available RIGHT NOW. No, none are in the main branch because none are good enough yet, and there's more than one way to skin the replication cat.

Bucardo
Slony
Londiste
Mammoth Replicator
and a half dozen or so more I can't remember right now. Each one, in its own right, is better than MySQL's built in replication. If someone submitted that pile of dog turds to the pg project it would never have been accepted.

I can tell you here and now that will never happen. Given MySQL's insane disregard for standards, the needed gutting of pgsql to allow it to behave in the same manner as MySQL is not going to happen, ever.

Silently ignore column level FK references?
Silently truncate ints that are too big to fit?
Silently allow int inserts into an enum to insert the int key directly without error?

There are way too many "oh dear god!" levels of gotchas in mysql to ever try implementing them in pgsql as a compatibility layer.

Now, there's a company out there that provides an Oracle compatibility level that works pretty well. That's something you can sell reasonably well.

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.

SCO is the only way to GO!

Sorry, but often putting 10 people on the same job one genius could do in a week results in a year long project that never reaches its goals. It's "The Mythical Man Month" at work.

I've been using the 1680 series for a couple of years now and they've been rock solid, for the most part. I had one that was delivered bad, replaced it and the replacement is running smoothly a year later. Have you got any kind of outside numbers that show them having a higher failure rate / data corruption rate? The brand I've had problems with in the past has mostly been adaptec.

I've built materialized views following the online tutorial for pgsql. Took me about 1 hour to set them up and have them working. And it's not simulating a materialized view, it IS a materialized view. With the materialized view, pg also uses the indexes on it. And you don't have to change the app, for christ's sake you just put the materialized view in place of the old view. You ever actually use postgres for much?

Next item on your list?

You can also cobble together some pretty cool stuff using plproxy and views.

This has been explained previously in this thread.

In Postgresql, schemas are equivalent to databases in MySQL. MySQL has no equivalency to PostgreSQL's database really.

Of course, I don't think you're actually looking for an answer, you're just being a mysql fanboi

MySQL was once much faster at lots of small queries. Now that's not so true. It's still faster, but only by a few percent most the time.

I know a lot of developers who had the same attitude you're putting forth, that they don't need complex queries. Then I rewrote their reporting apps which ran for 20 or 30 minutes by pulling in all the data one table at a time and munging it together. The same app, using pg to return the same data but do the work in the db dropped the time down into the sub minute range. As a bonus, the load on the db server went down too.

The type of thing MySQL is good at is content management, where the queries are usually simple and small. for that kind of stuff I can totally understand sticking with it. Like Slashdot!

I find slony works fine and scales well enough, but you often have to setup a star system. replicate to one slave, that replicates to all the other slaves and does nothing else. Also, slony runs slow on slower hardware, but on bigger 4 to 16 core servers with plenty of IO bandwidth, it runs quite quickly.

And when it stops replicating, there's a reason, usually my mistake, that it did.