PostgreSQL Wins LJ Editor's Choice Award 178
Quickfoot writes "PostgreSQL has won the LJ Editor's choice award for database servers the second year in a row and three times total (2000, 2003 and 2004). With the upcoming features in version 8.0 PostgreSQL is posed to do even better in 2005."
Current database server: PostgreSQL (Score:5, Funny)
My angst drives me to new lows.
My happiness is simply more to suffer thru.
Current Mood: depressed.
Current database server: PostgreSQL
Listening to: Linkin Park
Oh, Linux Journal.
Re:Current database server: PostgreSQL (Score:1, Troll)
Re:Current database server: PostgreSQL (Score:2)
PostgreSQL is an excellent DB (Score:5, Interesting)
The PGAdmin3 tool also allows for those scared/lazy for the command line to use interogate it's schemas.
What I'm not too sure about is where any company is providing support on a level one would get from Oracle or IBM. Oracle's support is actually extremely good (in my experience). Anyone point to any companies ready to provide PostgreSQL support?
Re:PostgreSQL is an excellent DB (Score:5, Interesting)
Developing for pgsql is also a lot of fun. The documentation makes it very easy to use, as well as develop for. I'd take PostgreSQL over Oracle, DB2, and especially MySQL.
Re:PostgreSQL is an excellent DB (Score:3, Informative)
Well, I'd certainly take it over MySQL, and I haven't used DB2 but it's optimizers look kindof sucky, so maybe DB2 as well.
However, I've seen Oracle perform miracles, and I've also seen the explain output from PSQL queries. The one thing PSQL needs in order to be a good OLAP (as opposed to OLTP) database is a really good query optimizer.
The primary problem I always ran into was that Postgres was always VERY optimistic when guessing row counts (if you actually perform the steps in the explain, you often ge
Re:PostgreSQL is an excellent DB (Score:3, Informative)
In order for the planner to do a good job, you must "VACUUM ANALYZE" regularly, not just "VACUUM". Or you could use "ANALYZE" by itself.
I would hope that 8.0 does a better job for you, I know they made some improvements to the planner.
Re:PostgreSQL is an excellent DB (Score:2)
PostgreSQL cannot do this due to it's design. It's MVCC datastore system means that you can only get the right number out of the actual table.
Re:PostgreSQL is an excellent DB (Score:3, Informative)
Re:PostgreSQL is an excellent DB (Score:4, Informative)
PLUG: Another good tool - PQA [postgresql.org], a SQL query analysis tool. Here's a sample report [postgresql.org].
Postgres Support (Score:2, Informative)
Google for Postgresql support and you'll find lots of support, including but not limited to:
Re:Postgres Support (Score:2)
Re:Postgres Support (Score:2)
They also support PostgreSQL. Josh Berkus, a member of PostgreSQL core, owns it. Please correct me if I'm wrong.
Re:PostgreSQL is an excellent DB (Score:3, Informative)
AFAICR the pggsql web site lists companies providing support.
Re:PostgreSQL is an excellent DB (Score:2)
example: in mssql, i can alter a table definition that has views defined against it, and if the resulting set is still consistent with the dependent views, no problem. in postgresql, i have to *delete* all the views (and i believe some other objects) that depend on the table, alter the table, and then recreate the dependent ob
Re:PostgreSQL is an excellent DB (Score:2)
Can you show what you mean? In PostgreSQL 8.0.0beta1, the following works
But what are they using? (Score:4, Informative)
Apache/1.3.26 (Unix) PHP/4.1.2 mod_ssl/2.8.10 OpenSSL/0.9.6e AuthMySQL/2.20
Right tool for the right job! (Score:4, Insightful)
Re:Right tool for the right job! (Score:2)
I don't get all of the zealotry on both sides. They are two fine databases, most stuff is not "enterprise" level requirements, so no suprise that you see MySQL all over the place. That doesn't make PG any "better" or "worse"!
You are so right !
In Economics you learn that "Quality" is defined by the consumer, not the producer or the industry.
For the majority of people needing a database, a simple, small and fast database server is of higher quality than a more feature-rich slower and complex server.
Re:Right tool for the right job! (Score:3, Insightful)
Re:But what are they using? (Score:5, Funny)
So you expect them to rewrite their site with the winning technology everytime they do these awards? You, sir, have a seat waiting for you in upper management.
Comment removed (Score:5, Interesting)
Re:Postgresql helps Linux pentrate corporates (Score:1, Offtopic)
Bet you're not the first database fan to wish for that.
(I love out of context comments.)
Re:Postgresql helps Linux pentrate corporates (Score:2)
I decided to look at what the prices were, and holy shit!
The "How to buy" [microsoft.com] page definitely needs the FAQ [microsoft.com].
In comparison, the many OSS licenses don't seem so bad/complex after all, and at least the price is right.
Re:Postgresql helps Linux pentrate corporates (Score:2)
That's probably $5k higher than I thought I remembered it being. They're no Oracle. And any server worthy of such an expensive database is going to have more than one processor. Who ever said nobody ever gets fired for recommending Microsoft?
Postgres rocks! (Score:3, Interesting)
I do wish there were two things:
(1) A Feature: multimaster asynchronous merge replication. This is Very Hard(tm) (and bogged down by patents in the corporate reich of america), but would make postgres a contender for distributed database applications.
(2) A model extension: distributed foreign keys. I think table inheritance isn't general enough. postgres has demonstrated that they're not afraid of going beyond the relational model. Well, I want a foreign key that can point to columns in two or more tables, and have a value from one OR another, yet still have its constraints enforced - why can't I specify e.g. A(X) REFERENCES C(Y) OR D(Z), so that A(X) may be a value from either C(Y) or D(Z), but nothing else?
And get rid of VACUUM (Score:2)
Am I missing something here? Tried to use postgres as the backing store for a java message queue. This involves very rapid INSERT, UPDATE and DELETE operations. Found that it starts out at 100+ transactions per second but drops to less than 20 per second after just one minute. Have to VACUUM [postgresql.org] continuously just to keep the average up. This is not a solution. How about a table option to eliminate redundant tuples in realtime instead of when VACUUM is run? As it stands, pgsql is not suitable for persistance in
Re:And get rid of VACUUM (Score:3, Insightful)
Re:And get rid of VACUUM (Score:5, Informative)
Databases inevitably have some point in a transaction where they require 2 versions of the same row to be present in persistent storage (on disk). That obviously means that the old version (or the new version in case of a rollback) has to be removed at some point in time. Some databases choose to do this on transaction commit, adding a little bit of overhead to each transaction. Some databases choose to do this in a separate process at scheduled intervals, reducing the commit overhead but adding the overhead of having more versions on disk. PostgreSQL has choosen the second path, and VACUUM is the cleanup process.
Which solution is the best depends on the requirements. As you have discovered, tables with a high turnover get easily bloated when the cleanup is not done frequently enough. The solution for that is to cleanup more often, with cleanup at commit of each transaction as the higher limit. But quite likely it is sufficient if cleanup occurs every X transactions or every Y seconds.
The intention was to have the pg_autovacuum utility integrated in the backend to manage the vacuum process for all databases in a cluster. If enabled, it would allow for automatic vacuum and analyze on tables, with some logic to learn if tables are high-turnover or fairly static. Unfortunately, the patch for that didn't make it into the 8.0 beta.
Re:And get rid of VACUUM (Score:2)
Re:And get rid of VACUUM (Score:3, Informative)
That's why PostgreSQL has VACUUM.
Moreover, VACUUM by itself just marks a row in the Free Space Manager (FSM) as free and writes over it at the next opportunity. VACUUM FULL will actually shrink the size of the table if that's what you need.
VACUUM should be automatic though, and eventually will be.
Re:And get rid of VACUUM (Score:2)
We have numerous servers that run a bunch of backends (so that each one has its own cache; ARC in 8.0 may relieve that need somewhat), and something we don't want is to have big vacuums chewing up I/O bandwidth on multiple backends concurrently.
I'd much rather have a "user space" daemon, so to speak, that can manage vacuums for multiple
Re:And get rid of VACUUM (Score:2)
It was added, it's just set to 0 by default, disabling it. But it's still in the code.
Re:Postgres rocks! (Score:4, Interesting)
Re:Postgres rocks! (Score:2)
FYI, OIDs are now optional, and may, in some future release, default to being off on a table at creation time.
Re:Postgres rocks! (Score:2)
That is an interesting thought and one that
Re:Postgres rocks! (Score:2, Insightful)
You know, generally the complaint about software patents being unreasonable has to do with how easy it is to do patented stuff. Have you considered that the only reason you know how to do multimaster asynchronous merge replication may be because someone figured out how to do it
Very little compelling reason to use MySQL anymore (Score:5, Informative)
What a difference a few years makes! Today, PostgreSQL is fast, extremely robust, and incredibly capable. It scales better than MySQL, preserves data integrity better, and makes it possible to do things that you can't do even in Oracle (for instance, just about all DDL in PostgreSQL is transactional: table creation/deletion, index creation/deletion, user creation/deletion, etc. This means, for instance, that you don't have to have an operator to alter a column's datatype: you just create the new column, copy the data into it, and then drop the old column, all within a single transaction, and if you screw up you can roll the whole thing back). It supports a number of different languages in which one can write stored procedures. The planner is quite good and yet is constantly improving.
About the only thing that PostgreSQL is not is auto-adaptive. That is, one still has to configure it to get optimal performance, same as with any database I've ever seen. The default settings provided in the raw distribution are, well, quite conservative: they're set up so that you can successfully start PostgreSQL even on a small, old system, which means you almost certainly have to tweak the configuration file in order to get truly good performance out of it.
In short, PostgreSQL has gotten very, very good in a relatively short period of time. It's so good compared with the other freely-available databases out there that I can't really think of a compelling reason to use anything else -- it's so good that if you need something more capable then you're going to have to pay big, big money.
And 8.0 will get you native Win32 support (with a point-n-click installer and everything, if I'm not mistaken). With its feature set (especially if you include what's going to be delivered in 8.0), that makes PostgreSQL-win32 a real SQL Server killer, as long as it performs well on that platform.
In short, PostgreSQL deserves very much to win this award, and the PostgreSQL development crew deserves a ton of kudos for producing such a kickass database system. I'm very much hoping that third-party software support for PostgreSQL gets as good as it is for MySQL, because the database engine is certainly deserving of it.
Re:Very little compelling reason to use MySQL anym (Score:2, Informative)
Actually, from PostgreSQL 8 you can use ALTER TABLE.
Re:Very little compelling reason to use MySQL anym (Score:3, Informative)
You aren't mistaken. The sort of install a Windows user will love -- although he will have to find PgAdmin III and create his own desktop shortcut.
With features like point-in-time recovery, I think we are going to hear a lot more about PostgreSQL this year.
Re:Very little compelling reason to use MySQL anym (Score:2)
Now I have a useful link [slashdot.org] to send to friends who are struggling with the MySQL / MS-SQL / Postgres decision. Do you write books, too? You should.
Re:Very little compelling reason to use MySQL anym (Score:2)
PostgreSQL uses up-to-date statistics to plan each query, meaning that when the data changes, the plans change also.
If you rely on planner hints and preplanned queries, then those hints or plans can become out of date, and slow you down.
Tools (Score:2)
Unless I am wrong and my information is outdated. I would like to learn more since I would prefer to leave mysql.
Native win32 port without a buggy cygwin implementation is a major plus.
Re:Tools (Score:3, Informative)
And by all standards I know, PostgreSQL is a true multiuser database. It supports concurrent access and acls (at many levels, the cluster, the d
Re:Tools (Score:4, Informative)
As I understand it, prior Point-in-Time recovery the WAL files would replay ALL of the transactions they contained, you could not pick were to end them.
With PIT you can tell the system to replay just to a certain point or all the way.
With the new utilities included with PostgreSQL 8.0(now beta) you can also use this as a backup system (it was not easy to do prior to this). Create a backup dump and load it into your backup server. Copy (rsync would work here) the WAL files over to the backup server and replay them as they compleate. When you need the backup, you can (using an included util) replay the last partial WAL file and bring the system up. If I were do this though I would most likely shrink the size of the WAL files from the stock 16MB to something a little smaller (unless your DB was VERY busy...).
BWP
Re:Tools (Score:2)
From my expirements, you can setup a nice log shipping setup. But if you have any intermittant failure of your backup system, You'll basically want to rebuild the backup database from a copy of the master.
There are a few posts about this on the pgsql-hackers mailing list. As well as a post about a possible long-term method of doing log shippin
Re:Tools (Score:2)
Still a little rough, but better than what some other systems have (ie nothing).
BWP
Re:Tools (Score:2)
If you're talking about "transaction checkpoints", what that means is nested transactions. It has nothing to do with handling database crashes; it's for limiting how much of your transaction you have to roll back when an SQL command fails. Say you issue these SQL commands:
If the second SELECT (for example) fails, the transaction is automatically aborted and you have to start over again with the firs
Re:Tools (Score:3, Insightful)
The most expensive task of a database is I/O. If you have a transaction that alters data in 3 places in two tables and that transaction commits, the database has to wait until the data has hit the disk. (Data hitting the disk is the Durability part from ACID.) With an average disk latency of 7 miliseconds doing 6 I/O operations translates to 42 miliseconds waiting before the database can confirm the commit to the client.
Since this is way to long, these 6 wr
Re:Tools (Score:2)
I am ignorant about sql programing but want to learn it when I have time.
Writing a sql app that is efficiant i/o is hard and your comment in informative. I have probably learned more from you than some of my books.
I would mod you up if I could.
Re:Tools (Score:2)
As its name implies, it allows you to recover your database to a specific point in time. This allows you to recover from an accidental DELETE FROM important_table or other user errors as well as hardware failures, etc.
Re:Tools (Score:2)
Re:Tools (Score:2)
PostgreSQL has as many or more and better recovery tools than MySQL today. Many of these are add-ons, however.
I also haven't had any trouble with the Cygwin implimentation except that it is remarkably difficult to set up. I do understand, however, that it doesn't scale well. The native Win32 implementation should be interesting to watch.
I would *highly* suggest looking at PostgreSQL.
Re:Tools (Score:2)
Programmable GUI (Score:3, Insightful)
Re:Programmable GUI (Score:1)
Why reinvent the wheel? (Score:3, Informative)
Re:Why reinvent the wheel? (Score:2)
I'm still trying to figure out how to log into phpPgAdmin. Sigh.
Re:Programmable GUI (Score:3, Informative)
What's wrong with Rekall [thekompany.com], or perhaps OpenOffice's DB interface (it works very well too) or maybe even using Microsoft Access [postgresql.org]. There's a commercial one from the UK too but I can't for the life of me remember the right incantation to bring it up in Google.
IIRC they are all programmable. Rekall's programmable in Python, OO in Java, Python and whatever else you can interface to it and Access in VB.
Re:Programmable GUI (Score:2)
TBH though we could do with a drop in replacement for access that uses a better DB backend (even mysql..) and has a VBA style scripting language etc.. so "apps" made in access can be ported super easily. Other languages e.g python, perl could also be available to make it more powerful and flexible.
Re:Programmable GUI (Score:2, Interesting)
Open standards/source
Web accessible, including management of the model and data.
It's not just basic database management needed, it's things like form and report design, and "code behind". I've got some ideas.
Re:Programmable GUI (Score:2, Funny)
Hundreds of unneeded parentheses and "DBA.everything"?
What about pgaccess (Score:2)
Re:Programmable GUI (Score:2)
Perhaps Gnu Enterprise [gnuenterprise.org] will suit your needs?
Re:Programmable GUI (Score:2)
Re:Programmable GUI (Score:2)
There is no technical link between Access and Jet; they are just bundled together. You can use Access with pretty much any ODBC data source including PostgreSQL.
Not a great idea.
LJ? (Score:2, Funny)
Who new LiveJournal gave out awards?
Please, No More PostgreSQL Publicity (Score:5, Funny)
PostgreSQL is an astonishingly great piece of software, one of the few best I've ever worked with.
Thus, if someone tells me they're using mySQL, which is not nearly as powerful as PostgreSQL , I can immediately surmise many things about them, their organization, and their code.
However, if PostgreSQL becomes well-known through all of this publicity, entities might inadvertantly start using it, making it more difficult for me to evaluate cluelessness.
Re:Please, No More PostgreSQL Publicity (Score:2)
I can summarise this: Since MySQL is offered on most hosting packages out there as an option, and PostgreSQL is offered on very few, the company in question is trying to maximise their potential sales, a shrewd move.
That is why techies do not make good CEO's, they usually (me included) want to implement what they see as the
Offentimes... (Score:2)
Moving hosting isn't something most non-technical people will consider unless they can see a clear reason to (blocked by spews, continual downtime etc.).
The best solution is when we host for customers, bec
Re:Offentimes... (Score:2)
As I said before, it's a moot point, our app works on both MySQL and PostgreSQL, but it's like releasing software for windows only (the MySQL of the OS world), lots of people do it because that's a large portion of the market taken care of. We go the extra mile and support postgre too, but many don't.
I recently dropped MySQL support from my CRM suite. I needed functionality which was going to be difficult to develop on MySQL and straightforward on PostgreSQL.
Of course, such an application can be hosted
Re:You are thinking backwards. (Score:2)
True, ONLY if there is ONE thing hosted.
The decision of where to host will be made, if technical factors are even considered at all, based on the initial guess at requirements.
As requirements are ADDED to the existing set, periodically the question of whether to stay or to move will be examined, with inertia and fear of the unknown tending toward staying. The problem with moving is that everything you do not kn
Re:Please, No More PostgreSQL Publicity (Score:2)
Oh look, some sibling rivalry. (Score:2, Insightful)
only to the novices (Score:5, Informative)
However, the differences here are quite substantial. And it isn't really 'mysql vs postgresql' - it's more like 'mysql vs inexpensive standards-compliant database solutions'. What really irks most experience database developers about mysql is that mysql abandoned decades of standards and standard features - while insisting that 90% of the users didn't need transactions, triggers, views, etc. That's disingenuous misinformation.
mysql still has a role out there - since it has such a wide host base and so much 'mind share'. But this is all marketing. In almost any technical comparison, Postgresql now comes out on top.
Furthermore, since postgresql is very similar to other relational databases - migration between it and oracle, db2, sql server, etc is relatively painless (unless you went overboard on stored procs, etc). This means that your investment in postgresql is fairly 'future-proof'. If on the other hand, you've gone with mysql, you will always have a more difficult migration - and may fail to get anticipated performance benefits since you are probably using the target database is a way not recommended by its vendor (joining inside application rather than inside sql, etc). This is especially true of the many mysql applications out there that believed MySQL AB when they told people that 90% of the applications didn't need transactions (!)
Of course, you can wait for mysql to catch up to everyone else in the database features area, and perhaps they'll try to become more standards compliant along the way. But that's going to be a tough slog for them, probably involving a complete rewrite. Could take quite a while, and there may be no easy transition for today's mysql apps.
Sibling rivalry? hardly
Re:only to the novices (Score:3, Insightful)
What's even worse is that they are now scrambling to add all that after years of arguing it was pointless to do so.
After they add triggers, views, stored procs what they will have is just another OSS database in a field already crowded with extrememly c
Re:Oh look, some sibling rivalry. (Score:3, Insightful)
With simply a good understanding of normalization and implementing genuine relational transactions, try to get MySQL to "work".
There truly is no comparison. They are not even siblings.
Re:Oh look, some sibling rivalry. (Score:2)
No, the differences are quite consequential, much more like differences between Linux and (say) Windows.
Consider:
MySQL(tm) is none of the above; it is, altogether, a proprietary system closely held by a singl
RDBMS vs OS (Score:2)
In this case it's more a case of, ooh, "DOS is better than BSD".
MySQL is the DOS of databases. Lightweight, runs reasonably quickly. Very, very feature-limited. When anything goes wrong, you lose your data - but there's always Norton Utilities to help you recover some of it. Doesn't require much skill to install or maintain. Acceptable if you need very little in the way of functionality in the OS/DB - either because you just don't need it in your application, or because you're prepared to expend the effor
PostgreSQL recovery model (Score:2)
Re:PostgreSQL recovery model (Score:5, Informative)
But with the advent of Point-in-Time recovery in 8.0 thats changed. With the new utils you can make a dump of the system and just copy it and the WAL files around. Database crash (that is not handled automaticly)? Just load the backup and replay the WAL files to whatever point in time you want them. You can even use partial WAL files.
BWP
And quite rightly so. (Score:4, Interesting)
Hell, it's even for simple, single-user database apps, especially when linked to a good ORM layer (EnterpriseObjects/GNUstep DB et al). Why more people doing web development don't push it, I don't know. Everything's bloody MySQL. Blech.
Oracle... (Score:2)
Re:Oracle... (Score:4, Interesting)
I am sure that there are people who know other things.
Re:Oracle... (Score:2)
uses direct / raw i/o
Re:Oracle... (Score:3, Insightful)
That has been hashed out on the mailing lists time and time again.
PostgreSQL is not a filesystem.
Where is the real use-case? There is a huge amount of extra code and extra bugs, and a minor performance optimization at BEST.
Additionally, PostgreSQL would then not be able to make use of OS disk buffers.
So, it would ONLY be useful as a MINOR performance optimization on PostgreSQL only machines, running NO other applications. All that at the cost of so much code and so many bugs?
You
Re:Oracle... (Score:2)
Re:Oracle... (Score:3, Informative)
To be fair pos
Re:Oracle... (Score:2)
You can do that in Postgresql.
Re:Oracle... (Score:2)
As I said though there are some features in pgsql that are not in oracle and visa versa. What do you need more? Ability to roll back a drop table or merge replication, ability to deal with XML data, great optimizer, and detailed stats about what your database engine is doing.
Comment removed (Score:3, Funny)
Re:Postgres ROCKS (Score:4, Funny)
Sadly, since their affections are misplaced, this is the last generation of PostgreSQL lovers.
Re:Postgres ROCKS (Score:1)
Re:Postgres ROCKS (Score:2, Funny)
Re:Learning Postgres! (Score:3, Informative)
Re:Learning Postgres! (Score:2)
I found the PostgreSQL book from SAMS to be a (Score:3, Informative)
Here it is on amazon [amazon.com]
Re:Learning Postgres! (Score:3, Interesting)
I don't have a recommendation but I do have a strong anti-recommendation.
I normally recommend the associated Oreilly [oreilly.com] book for most computer topics but in the case of PostgreSQL I have to say Practical PostgreSQL [oreilly.com] is the worst Oreilly book that I have read. Most of the book is a regurgitation of the freely available postgres manual [postgresql.org] with an additional chapter that is a blatant plug for the author's proprietary product.
I thought Oreilly could do no wrong until I bought this piece of crap.
Re:Speed v. Speed? (Score:3, Interesting)
Other than that, they are reasonably close in speed. However, I trust PostgreSQL to have better worst-case performance, and better query planning.
It depends on many factors and you should examine your application needs. You should also examine factors other than performance. Sometimes the performance might be similar, but
Re:postgresql challenge. (Score:2)
Go back to playing with Access and dreaming big while the rest of us get work done, would you?