This is just not true. If you were unwilling or unable to tune your DBMS, you can hardly go blaming PostgreSQL!
All you need to do is reduce your random_page_cost a bit, set your effective_cache to an appropriate value and bob's your uncle.
PostgreSQL can do optimisations that MySQL can only dream of. The reasons most of those posts are complaining about the optimiser is, let's face it, the users in question don't know about indexes. Another whole lot of them are about the slowness of IN () queries - which is now hundreds of times faster in PostgreSQL 7.4.
The deal with outer joins in PostgreSQL is that they are executed in the order you specify in your query. This means that you simply just have to have a couple of tries with it to make sure you haven't written a totally degenerate query.
There is discussion on allowing the optimiser to re-arrange outer joins, however it is a rather difficult problem theoretically to be able to prove that a certain rearrangement will still be an equivalent query.
Dude - if InnoDB actually had Foreign Keys that could cascade, then the totally non-standard SQL extension that is multi table deletes would be quite unnecessary.
Slashdot Mirror
No, it's mind-numbingly complicated. If it was easy, it'd have been done by now.
Chris
Try Slony for full, production quality replication on PostgreSQL:
http://www.slony.info/
I believe the windows version specifically CANNOT run as administrator, same as the unix version cannot run as root. For security reasons.
Not only that, but inside a PL/PgSQL stored procedure you can use the new TRY/CATCH exception handling to do stuff like this:
1. try an insertion into a unique column
2. value already exists, so catch the unique violation exception
3. try again from phase 1 with a new value
For example...
For up-to-date web-based administration of PostgreSQL, try phpPgAdmin:
http://phppgadmin.sf.net/
Erm, you've been able to rename tables in PostgreSQL for many, many years.
Check out the new Slony replication engine:
http://www.slony.info/
It is probably the best master->slave data replication engine for PostgreSQL at the moment. It is free and developed by one of the core developers.
That's a sound issue. Switch to DirectSound or OpenAL instead of the software renderer.
There is a lot of literally false information about PostgreSQL in that "comparison", including the privileges section.
I will contact the author to get it corrected...
Erm. PostgreSQL has had row-level locking for 10 years...
Hey Rob,
:)
I think you mean the keyword 'USING' instead of 'EXPRESSION'
Chris
If you want a great PHP interface to PostgreSQL, try phpPgAdmin:
http://phppgadmin.sourceforge.net/
Try phpPgAdmin:
http://phppgadmin.sourceforge.net/
This is just not true. If you were unwilling or unable to tune your DBMS, you can hardly go blaming PostgreSQL!
All you need to do is reduce your random_page_cost a bit, set your effective_cache to an appropriate value and bob's your uncle.
PostgreSQL can do optimisations that MySQL can only dream of. The reasons most of those posts are complaining about the optimiser is, let's face it, the users in question don't know about indexes. Another whole lot of them are about the slowness of IN () queries - which is now hundreds of times faster in PostgreSQL 7.4.
The deal with outer joins in PostgreSQL is that they are executed in the order you specify in your query. This means that you simply just have to have a couple of tries with it to make sure you haven't written a totally degenerate query.
There is discussion on allowing the optimiser to re-arrange outer joins, however it is a rather difficult problem theoretically to be able to prove that a certain rearrangement will still be an equivalent query.
Chris
PostgreSQL is at least as stable if not more stable than MySQL. The fact that it has a Write-Ahead Log has a LOT to do with that.
:)
MySQL's new features list reads like PostgreSQL's HISTORY file
Chris
One of the new features in PostgreSQL 7.4 is a new autovacuum daemon.
This daemon will monitor your installation and vacuum and analyze your tables automatically based on insert,update,delete rates, etc.
Chris
Make those NUMERIC(10,0) fields INTEGER and it will run a whole lot faster.
Dude - if InnoDB actually had Foreign Keys that could cascade, then the totally non-standard SQL extension that is multi table deletes would be quite unnecessary.
Chris
Ummm...Oracle does.
MySQL 4.0 supports UNIONS. I'm a PostgreSQL fan - but it's still important to get the facts straight.
Chris
Hrm. The contrib/fulltextindex in postgres is designed exactly to do what you want - simple indexing of some text fields.
Read the README.fti.
I have submitted improvements to it for 7.2 that let it index multiple fields per table, with better docs. We use it at work all over the place.
Chris
I'm a postgres developer and I really have no idea what you mean here!
Postgres always keeps its integrity constraints, including when you dump and restore. It's done this, as far as I am aware, since at least 7.0.
LOBs are no longer a problem, since 7.1 supported unlimited row length with binary or ascii data - just use 'bytea' or 'text' fields...
Chris
Hrm. I've had to dump/restore my old MySQL database enough times between versions - so I don't see how that's different to Postgres?
As for the query optimizer - why on earth do you trust your data to a database where you can't even optimize your queries.
At least postgres gives you partial indexes, functional indexes, histogram dispersion analysis of your columns, etc.
More power - but at a price: higher learning curve.
It's so worth it.
Chris