Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Databases Programming Software IT

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."
This discussion has been archived. No new comments can be posted.

PostgreSQL Wins LJ Editor's Choice Award

Comments Filter:
  • by BubbaThePirate ( 805480 ) on Sunday August 15, 2004 @07:08AM (#9973102)

    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.

  • by barcodez ( 580516 ) on Sunday August 15, 2004 @07:14AM (#9973115)
    PostgreSQL has for a long time been an excellent choice of database with full transaction support, sequences, trigers, unicode and much much more. I personally prefer working with it to expensive alternatives such as Oracle and DB2.

    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?
    • by digitalunity ( 19107 ) <digitalunity@yah o o . com> on Sunday August 15, 2004 @07:34AM (#9973155) Homepage
      PostgreSQL is also one of the oldest and most stable database servers around. Having been started in 1986 (1977 if you count Ingres development), it has had many years more of testing and development than probably any other open source project.

      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.

      • 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
        • Just to make this clear:

          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.
    • by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Sunday August 15, 2004 @07:53AM (#9973178) Homepage
      > The PGAdmin3 tool

      PLUG: Another good tool - PQA [postgresql.org], a SQL query analysis tool. Here's a sample report [postgresql.org].
    • Postgres Support (Score:2, Informative)

      Anyone point to any companies ready to provide PostgreSQL support?

      Google for Postgresql support and you'll find lots of support, including but not limited to:

    • Oracle's support is actually extremely good (in my experience). Yes, but I found it easy to use pgsql with no support, but impossible to use Oracle with no support!

      AFAICR the pggsql web site lists companies providing support.

    • i agree, it's a fantastic database. i'm porting our ms-sql-server stuff to postgresql ATM.

      ...but it suffers from a shortcoming that many open source projects have - ease of use.

      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

      • 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 objects. BIG hassle, especially while you're in the process of developing an application and the data definition changes.

        Can you show what you mean? In PostgreSQL 8.0.0beta1, the following works

  • by caluml ( 551744 ) <slashdot@spamgoe ... minus herbivore> on Sunday August 15, 2004 @07:17AM (#9973119) Homepage
    It looks like they are ( have been? ) quite big fans of MySQL [netcraft.com] in the past. Netcraft shows that a couple of years ago ( 4th Aug 2002 ) that their webserver was running with Mod Auth MySQL.
    Apache/1.3.26 (Unix) PHP/4.1.2 mod_ssl/2.8.10 OpenSSL/0.9.6e AuthMySQL/2.20
    • by pedestrian crossing ( 802349 ) on Sunday August 15, 2004 @08:31AM (#9973256) Homepage Journal
      If all you are doing is presenting web content without much in the way of heavy-duty transactional requirements (ie., no money is changing hands, mostly doing output as opposed to input), then MySQL is fine. Of course, PG would be fine as well. 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"!
      • 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.

        • I would think that in Economics "value" is defined by the user. Quality is also an abstract concept, but it is definitely not defined simply by how many people choose something. Who would argue that McDonald's is high quality, even if they regularly eat McDonald's?
    • by SlashdotLemming ( 640272 ) on Sunday August 15, 2004 @09:40AM (#9973469)
      It looks like they are ( have been? ) quite big fans of MySQL in the past. Netcraft shows that a couple of years ago ( 4th Aug 2002 ) that their webserver was running with Mod Auth MySQL.

      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)

    by account_deleted ( 4530225 ) on Sunday August 15, 2004 @07:20AM (#9973122)
    Comment removed based on user account deletion
  • Postgres rocks! (Score:3, Interesting)

    by Anonymous Coward on Sunday August 15, 2004 @07:24AM (#9973129)
    The thing I like about it is that they're not scared of going beyond the basic SQL [tablizer-mode:pseudo]relational model, with their business rules, advanced user-defined-types, and table inheritance. And MVCC is amazing!

    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?

    • 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

      • Whats the problem with running VACUUM? You just start VACUM as a cronjob. It's not as if it stops the database from working.

      • by JohanV ( 536228 ) on Sunday August 15, 2004 @10:42AM (#9973681) Homepage
        Continuous VACUUM actually is the solution. It just should be automatic instead of manual.

        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.
        • The solution in Interbase/Firebird (original MVCC?) was to setup the 'sweep' process to run when too much of a difference exists between transaction numbers (old/new active/useful -- it's a mess). You can disabled it and run sweeps manually, and they're not needed if you backup/restore on a regular basis, but eh ... Firebird also cleans up unneeded record versions each time it reads a row (as I recall) to keep the db as clean as possible. That slows it down a bit on reads, but prevents rows from accumulatin
        • The "old" row cannot be deleted at transaction commit! Other transactions might still be reading it.

          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.
        • I have done some work on pg_autovacuum, but have been not entirely thrilled with it, and, furthermore, am really not thrilled with the integration with the backend.

          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

          • There's a "sleepy vacuum" thing that was almost added to 7.4 where you can set vacuums to sleep a few milliseconds every few blocks.

            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)

      by rycamor ( 194164 ) on Sunday August 15, 2004 @09:05AM (#9973344)
      Actually, there is nothing non-relational about the idea of a distributed foreign key. It has even been proposed by some ardent "defenders" of the relational model: Hugh Darwen (colleague of C.J. Date) mentions this as a desirable feature in his presentation How to Handle Missing Information without Using Nulls [freeola.com]
    • (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?

      That is an interesting thought and one that
    • Re:Postgres rocks! (Score:2, Insightful)

      by jguthrie ( 57467 )
      AC Sez:

      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.

      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

  • by kcbrown ( 7426 ) <slashdot@sysexperts.com> on Sunday August 15, 2004 @07:35AM (#9973157)
    Way back in the day (late 90s), PostgreSQL was quite slow, not all that reliable, and difficult to bring back up after a crash. It was during this time that MySQL became very popular: it was fast, if not terribly robust, but the MySQL developers were very smart by providing tools that would "fsck" your table files so you could bring your database back up after a crash without too much headache (PostgreSQL required a full restore, which took much more time).

    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.

    • "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"

      Actually, from PostgreSQL 8 you can use ALTER TABLE.

    • And 8.0 will get you native Win32 support (with a point-n-click installer and everything, if I'm not mistaken).

      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. :) Pretty cursory look so far but I imported a db I'm working on from Debian and my more complex procedures ran fine.

      With features like point-in-time recovery, I think we are going to hear a lot more about PostgreSQL this year.
    • Thank you so much for that post. You put into words what I've experienced, daily, but could never summarize so well.

      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.
  • Recovery tools for example as well as multiple user support keep mysql more popular among ISP's.

    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)

      by JohanV ( 536228 )
      PostgreSQL has buildin recovery. Upon every boot the system verifies if it was correctly shut down and if not it replays the Write Ahead Log (WAL) from the last checkpoint (which occur every X seconds and force all data to be written to disk) until the last committed transaction. That is all recovery you need in a database, and it has been in PostgreSQL for years.
      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
    • MySQL is still popular with ISP's IMO because that is what they know and there are many applications which support it.

      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.
  • Programmable GUI (Score:3, Insightful)

    by bogaboga ( 793279 ) on Sunday August 15, 2004 @07:42AM (#9973164)
    I am very very impressed by PostgreSQL. I am waiting for the geeks to slap a programmable GUI onto it. I know there are several that I can mention here, but none comes even half close to what M$'s Jet engine has with Access. I once tried to put together one with PHP but the project became very complex for my managing. I abandoned the effort. Slashdotters, can we start another project to put a decent GUI onto this DB engine? When that is done, business logic can be programmed at form level, reports can be done in XML and published to PDF, even better, error handling at form level with input masks etc can be done. And before you go on, I'd like to remind you that there is Kexi, pgAdmin and so many others. What do you think?
    • Nice idea... Can't Access be slapped on via ODBC or something? (However, I'd suggest you'd be wanting to put a webfront-end on it, and would be concerned with anything needing more than half a dozen simultaneous users with Access even to a DB like postgres)
    • Try out phpPgAdmin [sourceforge.net] which does exactly what you were probably trying to set out to do in PHP.
    • Re:Programmable GUI (Score:3, Informative)

      by tzanger ( 1575 )

      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.

      • They do sound good I agree.

        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.
    • That sounds like a great idea. Create something a bit like a form/report/database tool to challenge the MS Access space, but add in a few other things...

      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.

    • I know there are several that I can mention here, but none comes even half close to what M$'s Jet engine has with Access.

      Hundreds of unneeded parentheses and "DBA.everything"?

    • I am very very impressed by PostgreSQL. I am waiting for the geeks to slap a programmable GUI onto it.

      Perhaps Gnu Enterprise [gnuenterprise.org] will suit your needs?
    • Can't OO.org use pgSQL through ODBC connectivity?
    • I am waiting for the geeks to slap a programmable GUI onto it. I know there are several that I can mention here, but none comes even half close to what M$'s Jet engine has with Access.

      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.

      When that is done, business logic can be programmed at form level

      Not a great idea.

  • LJ? (Score:2, Funny)

    by SlamMan ( 221834 )
    PostgreSQL has won the LJ Editor's choice award for database servers the second year in a row

    Who new LiveJournal gave out awards?
  • by occamboy ( 583175 ) on Sunday August 15, 2004 @08:01AM (#9973192)
    All of this recent publicity around PostgreSQL is making me nervous. You see, I've been using PostgreSQL as both a database AND a clue test.

    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.

    • 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.

      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
    • In that case you can use firebird or SAPDB as a litmus test.
  • Ahhh the debate returns. MySQL and PostgreSQL are really no different than debating linux distrubutions and (possibly) operating systems; they have been formulated to do quite different things, and different people favour them for different reasons. However, once you have begun to use one or the other, and you begin to understand how you bend it for what you want done, I think you simply trust it and favour it over the alternatives. I think this expalains why I've personally always preferred MySQL. Poss
    • only to the novices (Score:5, Informative)

      by kpharmer ( 452893 ) * on Sunday August 15, 2004 @11:02AM (#9973748)
      You can always dismiss any heated debate as simply a result of nit-picking or personal preferences.

      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
      • "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."

        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
    • If you really should be using flat files (for read-only "speed"?) but want to look SQL-cool, MySQL will win you over, hands down. But don't let the "SQL" in MySQL fool you.

      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.
    • MySQL and PostgreSQL are really no different than debating linux distrubutions

      No, the differences are quite consequential, much more like differences between Linux and (say) Windows.

      Consider:

      • PostgreSQL is developed as a community project. Some developers are sponsored by companies, much as is the case with most projects in the "open source community," but the results are essentially publicly owned.

        MySQL(tm) is none of the above; it is, altogether, a proprietary system closely held by a singl

  • I looked at the documentation and something was left unclear. I understand that backkups are made using the pg_dump command to script the entire database to stdout. Does PGSQL have the ability to do incremental backups consisting only of the transactions since the last pg_dump or do you have to take the full backup every 30 minutes or so, which sounds hugely wasteful?
    • by bovinewasteproduct ( 514128 ) <gclarkii@@@gmail...com> on Sunday August 15, 2004 @10:13AM (#9973585) Homepage
      Prior to 8.0 you just about had to do that, but with the ability to use gzip to compress your archives, it was not too bad unless you had lots of bytea or blobs in the DB.

      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
  • by Anonymous Coward on Sunday August 15, 2004 @09:36AM (#9973450)
    PostgreSQL has, for some time, been more scalable and more reliable than MySQL, which is, IMNSHO, a mere toy by comparison. I've pushed PostgreSQL to several major corporate clients, who have been more than happy with it (indeed, some have added stuff on and pushed the changes back to the main source base, something I would not have considered likely from the sort of corporates I'm talking about)

    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.
  • Here's the question I find interesting. PostgreSQL is widely considered to be an awesome database system. What does Oracle have that PostgreSQL doesn't? What else does PostgreSQL need to be considered the equal or better of Oracle?
    • Re:Oracle... (Score:4, Interesting)

      by chthon ( 580889 ) on Sunday August 15, 2004 @10:48AM (#9973708) Journal

      • Support for more compiled programming languages : Ada, Cobol
      • Clustering/distributed database

      I am sure that there are people who know other things.

    • oracle supports multimaster
      uses direct / raw i/o

      • Re:Oracle... (Score:3, Insightful)

        by jadavis ( 473492 )
        uses direct / raw i/o

        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
        • I've seen dedicated oracle machines make use of raw / direct I/O but of course these were huge >=8 way systems supporting ATT, Sprint, MCI etc. Most DB requirements aren't so demanding.
    • Re:Oracle... (Score:3, Informative)

      by killjoe ( 766577 )
      First and foremost it has merge replication and real application clustering. Of course you need to spend buttloads of money to get the clustering. It's also extraordinarily self aware. For example you can have oracle email you the list of 10 slowest queries that ran yesterday. It's full of amazing stats about itself that really helps the DBA out when they are trying to troubleshoot weird problems. Oracle also has tons of other features such as dealing with XML data using SQL or xpath queries.

      To be fair pos
      • Can you rollback a "DROP TABLE" in Oracle?

        You can do that in Postgresql.
        • Not quite a rollback but you can do point in time recovery.

          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.
  • by account_deleted ( 4530225 ) on Sunday August 15, 2004 @04:53PM (#9975779)
    Comment removed based on user account deletion

If all else fails, lower your standards.

Working...