Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Databases Programming Software IT

PostgreSQL 8.0 Enters Beta 368

Posted by CmdrTaco from the get-your-db-on dept.
gavinroy writes "As announced in pgsql-announce, PostgreSQL 8.0 Beta is now available. New features include native win32 support, Point in Time Recovery, Tablespaces, and much more! here is the beta history if you want more information."
This discussion has been archived. No new comments can be posted.

PostgreSQL 8.0 Enters Beta More

PostgreSQL 8.0 Enters Beta

Comments Filter:

  • You can save a few clicks... (Score:5, Informative)

    by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Tuesday August 10, 2004 @12:03PM (#9930234) Homepage
    ...and jump right to the beta announcement message [postgresql.org].
    • Apologies to Ziff-Davis...

      From: "Marc G. Fournier"
      To: pgsql-announce ( at ) postgresql ( dot ) org
      Subject: PostgreSQL 8.0.0 Officially Goes Beta
      Date: Mon, 9 Aug 2004 21:36:52 -0300 (ADT)

      After almost 9 months of development, the PostgreSQL Global Development Group is proud to announce that development on PostgreSQL 8.0.0 has now finished, and is ready for some serious testing.

      For those wondering about the 8.0.0 designation on this release, there have been several *very* large features included i

    • Thank you Fujitsu And Afilias. (Score:5, Interesting)

      by ron_ivi ( 607351 ) <sdotno@cheapcomp ... m ['ces' in gap]> on Tuesday August 10, 2004 @12:20PM (#9930462)

      I just wanted to say thanks to Fujitsu for helping pay for this [newsforge.com]

      Fujitsu foots the bill for new PostgreSQL database features
      Thursday July 01, 2004 (07:04 AM GMT)
      ...
      Berkus described the new Fujitsu-formed features as follows:

      * Tablespaces is a means of partitioning large amounts of data easily and efficiently on separate storage devices, a key requirement for maintaining PostgreSQL's performance on large databases in the hundreds of gigabytes, and terabyte range;
      * Nested Transactions allows application developers a very granular level of control over database commits and rollbacks, which is particularly significant for maintaining data integrity and porting applications from other database platforms;
      * Robust support for stored procedures in Java that exceeds the goals of the SQLJ specification in the ANSI SQL99 standard.
      And thanks to Afilias (the guys who run the .org domain) - from the same article:
      More recently, .org and .info domain registry company Afilias has sponsored developer Jan Wieck to work full time on developing a new, enterprise-class replication system for PostgreSQL called Slony-I, to be presented next month at OSCON in Portland, Ore.
      • DOes anybody know if the new replication will support merge and multi-master replications. Even ring replication a-la mysql would be better then one way master-slave replication.
      • ...a new, enterprise-class replication system for PostgreSQL called Slony-I
        PostgreSQL is good from a technical point of view, but they could use someone with some very basic PR and marketing skills on their team. A new website and better documentation wouldn't hurt either.

        • Strongly disagree.

          The PostgreSQL website is easy to navigate and easy on the eyes. Links to anything most users will need -- downloads, docs, and search -- are right at the top of every page.

          The MySQL website uses microfonts, and good luck finding documentation without resorting to google site:mysql.com; there's links to it on some pages and not others, and most notably not on the front page. The MySQL website is, apparently, trying to be oracle.com, only worse.

          The difference is pretty simple: The postgresql developers are trying to write a database server. Selling it is not their concern, nor is marketing it to the world: they let others (mostly, their users) do that while they focus on development. MySQL, on the other hand, is a business: they need customers to survive, and sometimes the technology takes a back seat to the business side of things.

      • Re:Thank you Fujitsu And Afilias. (Score:4, Interesting)

        by Earlybird ( 56426 ) <slashdot @ p u r e f i c t ion.net> on Tuesday August 10, 2004 @03:36PM (#9932863) Homepage
        • More recently, .org and .info domain registry company Afilias has sponsored developer Jan Wieck to work full time on developing a new, enterprise-class replication system for PostgreSQL called Slony-I, to be presented next month at OSCON in Portland, Ore.
        Except Slony-I [postgresql.org] is a single-master/multiple-slave replication system -- hardly "enterprise-class".

        What's slightly noteworthy about Slony is that it has "switchover" support. If the master fails, one of the slaves become the master.

        Of course, since Slony's replication is asynchronous, it means that at the point of switchover, slaves might not have received all pending changes, thus becoming out of sync with the master. Unfortunately, Slony doesn't really address this problem.

        The design overview [postgresql.org] is useful reading, if rather confusing; the writer's first language is probably not English.

  • where to download (Score:5, Informative)

    by jbellis ( 142590 ) * <jonathan@carDEBI ... com minus distro> on Tuesday August 10, 2004 @12:06PM (#9930273) Homepage
    http://developer.postgresql.org/beta.php

    the windows installer is at
    http://pgfoundry.org/projects/pginstaller

  • BitTorrent Downloads (Score:5, Informative)

    by Anonymous Coward on Tuesday August 10, 2004 @12:07PM (#9930280)
    http://bt.postgresql.org

  • I recommend Mysql users to take a look at PG (Score:4, Insightful)

    by xutopia ( 469129 ) on Tuesday August 10, 2004 @12:09PM (#9930308) Homepage
    it is the most advanced Open Source database there is. If anything pissed you off with MySQL chances are Postgresql will have a solution for you.

  • Die IT theme (Score:4, Funny)

    by ScytheBlade1 ( 772156 ) <scytheblade1@NOsPam.averageurl.com> on Tuesday August 10, 2004 @12:10PM (#9930326) Homepage Journal
    Die IT theme. [slashdot.org]
  • I remember reading a document somewhere for mysql that explains what each part of a version number "really meant". The major version number meant that the format of the databases will change (or could change). Is this also the case for postgres I wonder?

    • Yes (Score:2)

      by jbellis ( 142590 ) *
      ... which you would know if you'd RTFA :P

    • Re:What the versions mean (Score:5, Informative)

      by SSpade ( 549608 ) on Tuesday August 10, 2004 @12:25PM (#9930512) Homepage

      In the case of postgres there are three digits in the version - a.b.c

      If your upgrade increases either a or b then the on-disk structure of the database has changed, and as part of the upgrade you'll need to dump the database out to a backup file and restore it.

      If the only change is in the final digit c then there's no on-disk change and you can upgrade just by upgrading the binaries. That tends to mean that final digit upgrades are bug fixes, and you should always do the upgrade.

      So if you're running 7.4.1 you can easily, and definitely should, upgrade to 7.4.3. But upgrading to 8.0 is a marginally more time-consuming upgrade that you may not want to make on a production system unless you want the new features in 8.0

      There's no 'technical' difference between a first digit change upgrade and a second digit upgrade. There's a difference in expectations though, and the version following 7.4.* has enough major new features to justify a major version jump to 8.0.0, with all the positives and negatives that jump implies. The upgrade path would have been identical had it been called 7.5.0 though.

      • Thanks. Someone should mod you up to informative because that's some good info to know.
      • There's no 'technical' difference between a first digit change upgrade and a second digit upgrade.

        As I understood from reading the lists, there is a technical distinction. a.(b+1).c is supposed to be more stable than a.b.d, even though it may have some additional features.

        8.0 added so many powerful features that the developers did not want to imply that it would be more stable than 7.4. 7.4 is pretty much rock-solid, and 8.0 might not achieve that reputation until 8.1 or so.

  • Can it Compete with Oracle or DB2? (Score:5, Interesting)

    by Greyfox ( 87712 ) on Tuesday August 10, 2004 @12:12PM (#9930349) Homepage Journal
    I was interviewing with a company a while back that was planning to move from an Oracle based set-up to a Postgres based one. They were pushing enough data around daily that they were having to redesign their collector software to be more efficient, so I was somewhat concerned that Postgres wouldn't give them the performance they needed, but I haven't really seen enough of it to be able to comment.

    On the other hand, I've seen both Oracle and DB2 corrupt indexes and database table data in various circumstances (Usually the failing of a DBA in some capacity or other.) I'd be curious to see how the various databases stack up against each other without the hype that most of the parties that publish such studies usually bring to the table.

    • Re:Can it Compete with Oracle or DB2? (Score:5, Informative)

      by rtaylor ( 70602 ) on Tuesday August 10, 2004 @12:29PM (#9930562) Homepage
      PostgreSQL is a touch slower than Oracle in some special cases (single user on multi-cpu machine doing large or very complex queries) since Oracle can split the work up amongst CPUs.

      With 50 to 100 users, both have similar performance for many workloads (you need to test your specific workload), but Pg may require a touch more tuning.

      Pg is, however, quite a bit more reliable than Oracle as far as corruptions go (keeping in mind this is a .0 release) so long as the hardware is adequate (doesn't lie about writes hitting disk when they're really in cache).

      There are ways of purposfully crashing PostgreSQL as an authenticated user (particularly if you have root access and can write functions in C), but in standard operation it's quite reliable.

      I cannot speak for DB2, but based on their Docs I think Pg is nearly as feature complete in most areas, and much more complete in many others.
      • That's the exact opposite of most peoples' experience.

        (From someone who used to wear Oracle DBA as one of his hats.)
        • Yes, that's most peoples experience -- but recently there have been a few migrators going from Oracle to PostgreSQL who found it difficult to get Pg to run the queries the way they wanted.

          Of course, those situations often result in planner or optimizer patches and the next version doing better for everyone :)

      • Re:Can it Compete with Oracle or DB2? (Score:5, Insightful)

        by Stone316 ( 629009 ) on Tuesday August 10, 2004 @12:48PM (#9930781) Journal
        There's more to a database than feature set. While postgreSQL has enough features for 98% of the applications out there it isn't that simple.

        In 8 years i've never lost data from an Oracle database from a software problem. I've seen data get lost, corrupted for a number of reasons including incompetent DBA's and their managers. (Off topic but once I was called into a major telephone company because they had some corrupted blocks from a hardware issue. I asked them how long did they keep their backups, 3 months they replied. Ok, how long have you known about this problem, 5 months. Hrmm... 3 - 5 = -2. You can fill in the rest of the story..)

        I haven't used postgreSQL in a production environment long enough to know how stable it is. The reason companies choose commercial vendors for their DB's are two fold:

        1) Track record. They know if they pick Oracle or DB2 they are getting a solid,proven database system. And there is an abundance (if not expensive) of knowledge out there. Their support is bar none and for the most part I have been extremely satisfied.

        2) Managemnt loves to save money. Who wouldn't want to be able to say they saved the company millions of dollars by going to a 'free' or inexpensive (if you pay for support) rdbms like postgresql or mysql. One reason, blame. Opensource still has the stigma attached to it that no one is accountable for bugs. If a critical revenue generating db goes down because of a bug a manager needs to be able to point their finger. Until this stigma goes away we won't see alot of opensource adoption in the DB market. Whether this is right or wrong doesn't matter, people don't like change and opensource is a huge change for alot of managers.

    • Re:Can it Compete with Oracle or DB2? (Score:4, Informative)

      by ron_ivi ( 607351 ) <sdotno@cheapcomp ... m ['ces' in gap]> on Tuesday August 10, 2004 @12:31PM (#9930586)
      Computerworld had an interesting article of the case when PostgreSQL beat Oracle [computerworld.com.au](cool) to enable Afilias to power the .org domain when they took it away from Verisign (also cool).

      Here's the ISOC's response to Oracle FUD. [icann.org]

      We believe that the key point relating to databases for the .ORG
      redelegation is not which database the operator is using, but,
      rather, whether the database will support the .ORG registry in a
      stable, scalable, and highly available manner.

      Afilias has over a year of experience running a large scale gTLD
      registry--the .INFO registry. This direct experience, the load &
      stress tests conducted by Afilias (and listed in our proposal
      <http://www.icann.org/tlds/org/applicati ons/isoc/section3.html#c17.10>),
      and Afilias' compliance with ICANN's service level requirements clearly
      demonstrate that the PostgreSQL database used by Afilias performs
      at the level of reliability and availability required for the
      mission critical operations of a global gTLD registry.

      Further, the actual operating performance record of Afilias compares
      very favorably to the records of the other .ORG applicants, many of
      whom use commercial databases. A review of each bidder.s answers to
      Question 14 <http://www.icann.org/tlds/org/questions-to-applic ants-14.htm>
      illustrates the kind of hard data and real world registry experience
      that ICANN is basing its decision on. Afilias has delivered this level
      of performance based in part on its stable, reliable database, PostgreSQL.

      The successful operation of a registry extends beyond simply which
      database software is in use. It also requires a skilled operating staff
      with the ability to design and implement reliable systems as well as
      establish clearly defined resolution paths should problems occur.
      Afilias' solid operating performance lends support to the claims in our
      .ORG proposal regarding our ability to effectively manage the .ORG domain.

      We do not take issue with the recitation of the many features and
      benefits of Oracle's products. However, any suggestion that PostgreSQL
      is unsuited for registry use is in direct contradiction to the facts.
      • Better, you can see all the competitors for .ORG answering ICANN's questions about databases here [icann.org]. It has the best summaries of Oracle vs PostgreSQL I've seen, because it comes from vendors competing for a big project arguing their pointts.

        Oh, and a link to Oracle's FUD [icann.org] when they were trying to keep control of the .org comain: "PostgreSQL is used primarily in the embedded system market because it lacks the transactional features, high availability, security and manageability of any commercial enterpr

    • Re:Can it Compete with Oracle or DB2? (Score:5, Informative)

      by Stone316 ( 629009 ) on Tuesday August 10, 2004 @12:33PM (#9930604) Journal
      In my 8 years as an Oracle DBA I don't think i've ever seen a corrupt index. Saying that, I don't even know how you could force a index to get corrupted so I don't think were seeing all the info here.

      There is alot of hype in the database market as is there with any other area such as OS preference. A good DBA, like a good software developer will pick the database that fits the needs. Saying that, usually DBA's (like anyone else) are under certain constraints from management but heres my take:

      For:

      Mission Critical Apps and large DB's: Oracle or DB2
      Mid-Range apps/Mid-sized DB's: The above + SqlServer, PostgreSQL.
      Small: SqlServer, PostgreSQL. (+ Oracle and DB2 if you like to toss around the $$).

      I'd feel comfortable using PostgreSQL for upto and including mid-sized DB's. Currently I wouldn't use mySQL for anything until they fix their Gotcha's. [sql-info.de]

      If you really and I mean really have faith in your developers and they have reviewed these gotcha's i'd consider MySQL but unfortunately, as every DBA knows this isn't always possible. It only takes one bad apple to mess everything up.

      Of course there are many other factors to choosing a database but the core comes down to your employees and licensing. If all your DBA's have extensive training on Oracle then it doesn't make much sense to retrain them to use another DB just because it maybe a better fit. Also, if you have a server license for Oracle it doesn't make much sense to buy another so you can use DB2.

      At our shop we have a mix of Oracle and SqlServer. But we do installs for DB2, Redbrick, informix, everything and anything under the sun.

      Anyways, thats my 2 bits.
      • Oracle for "mission-critical"? I don't see how any one could feel comfortable putting the life of their company in the hands of another company like that.

        • Oracle for "mission-critical"? I don't see how any one could feel comfortable putting the life of their company in the hands of another company like that.

          So they should code their own RDBMS and put the life of their company in their own, likely non-RDBMS-expert hands? Maybe I missed your point but I don't see how your post make any sense?

          • If they use an RDBMS they have the code to, yes, they have the option of bringing an RDBMS on staff and doing custom improvements and fixes. However, they also have the option to go hire some other company to make the fixes and improvements they need.

            The user of PostgreSQL has a whole market of developers to choose from. The user of Oracle has only one choice, and that company is known for taking a monopolist*'s rents from its customers.
      • Out of curiosity - what would you consider a "Large DB"?
        • Well, when I say large DB i'm referring to a combination of data, users and application. You could only have a couple of gigs of data but hundreds/thousands of simutaneous users, so that would be a large DB.

          On the other hand you could have a relatively low number of users, say a data warehouse but have hundreds of gigs of data.

          Application complexity plays a part as well. So if your asking me its hard to set ranges as to what is/isn't a large database.

      • Small: SqlServer, PostgreSQL. (+ Oracle and DB2 if you like to toss around the $$).

        Don't forget that Oracle Standard Edition One is less expensive than SQLServer.

      • In my 8 years as an Oracle DBA I don't think i've ever seen a corrupt index. Saying that, I don't even know how you could force a index to get corrupted so I don't think were seeing all the info here.

        I have. As the original poster said, there is usually a DBA involved.

        You want to see Oracle corrupt something? Easy. Just install a half dozen oracle homes, from 8.0.6 through 9i, use any random version of sqlplus, sqldba that happens to be in the path to do things like create new tablespaces on whatever
      • And you know what? If people would license Oracle only for Mission Critical Apps and large DBs, Oracle would be bankrupt tomorrow.
        At least if I extrapolate what I'm seeing in the enterprise, Oracle's total revenue would go down 80%. That's why they were already FUDing around in 2002 when the decision about the .org domains was made (hardly something which would justify paying $$$ to Oracle).

  • Let the flames begin (Score:3, Funny)

    by Gothmolly ( 148874 ) on Tuesday August 10, 2004 @12:12PM (#9930351)
    (MySQL|MSSQL|Oracle|DB2) is (cheaper|better|faster|ACID-compliant|'1337) and Postgres is (slower|buggier|missing features|has broken features|sucky)!!!
  • Is there a database (more heavyweight than SQLite) that allows you to specify where in the file system it keeps it's records?

    Has any project ever built a IOSLAVE/VFS/LUFS filesystem bridge to a relational database?
    • "Tablespaces allow administrators to select the file systems used for storage of databases, schemas, tables, or indexes."
    • Yes Postgres does.
      Set $PGDATA to where you want the files stored.
    • Berkely DB [sleepycat.com] AKA libdbX.

    • Re:Database Questions (Score:5, Insightful)

      by ciroknight ( 601098 ) on Tuesday August 10, 2004 @01:59PM (#9931770)
      To the second question: Nobody in the open source world.

      Microsoft's on the way to doing it, and there was a small project that existed for a few months that allowed GNOME to access a database as a file system (It was very nasty; involved a kernel patch (a CORBA orb) that nobody was too happy about, so the project never took off.)

      I've thought about the problem a few times. It requires the kernel pass information back to user space, unless the database was actually incorporated into kernel space (and that won't blow over well for a number of reasons). Passing the data back to user space requires a messaging system. The problem is, there are very few messaging systems out there designed specifically for kernelspace-userspace communication. CORBA was one developers answer; my answer would to be to ground up a protocol (because I feel that a network messaging solution, i.e. TCP/IP, can't be secured well enough in the long run).

      Lastly, a daemon needs to exist to listen to the calls from the kernel and interpret them into SQL. This could be built into the kernel itself, but once again you have to question the security of the kernel building an SQL query that would go directly to the database server. Also, one of the better parts about this daemon would be metadata extraction; since the daemon is virtually transparent to both the user and the database server, the metadata can be completely ripped from the data and stored in a seperate table to allow for much faster, more optimised searches. EXIF Tags can be copied from JPEGs, ID3 tags copied from MP3s, etc.

      Ideally, the daemon would be pluggable, allowing for anyone's metadata extension to be added after compiliation, but I believe that it's important to have a functional system before having a featureful system.

      If you'd like to talk more about it, I'm really open to the idea of finally having an SQL-based file system. A relational database file system is the future; if we get there before Windows, we can add yet another example of the speed of open source development.

  • Native Win support - awesome (Score:5, Interesting)

    by Stone316 ( 629009 ) on Tuesday August 10, 2004 @12:13PM (#9930364) Journal
    I think this was a major stumbling block for postgreSQL's adoption. I'd love to use it here at work for some small projects but unfortunately were getting more and more windows servers. PITR recovery is a must for any production database these days. Maybe there are some 3rd party packages but I don't think mysql supports this yet. This is great news and I hope it spurs a new round of adoption for pgsql!

  • Windows support (Score:5, Interesting)

    by Anonymous Coward on Tuesday August 10, 2004 @12:14PM (#9930380)
    I think Windows support is the only reason MySQL is so popular. PostgreSQL has always been ahead of MySQL in terms of everything but speed. But everybody is familiar with MySQL because, when you want to pick something up, you pick the one that will work with your system, and most people are on Windows.

    Up until this point, you have had to install hundreds of MB of cygwin to get PostgreSQL to work on Windows. I think it's a little late to usurp MySQL's market share, especially as MySQL is now entrenched in the cheap web hosting market, but at least PostgreSQL might get the respect it deserves.

    • MySQL faster than postgresql? (Score:4, Informative)

      by jbellis ( 142590 ) * <jonathan@carDEBI ... com minus distro> on Tuesday August 10, 2004 @12:23PM (#9930489) Homepage
      Maybe if you only have one client querying the DB, and you're not using any features newer than SQL-89. Maybe.

      Back in the 6.x days postgresql had a well-deserved reputation for being, well, slow. That was back in the '90s, though.

    • Re:Windows support (Score:5, Insightful)

      by Khomar ( 529552 ) on Tuesday August 10, 2004 @12:34PM (#9930615) Journal
      I think Windows support is the only reason MySQL is so popular...ahead of MySQL in terms of everything but
      speed. (emphasis added)

      You cannot overlook the speed aspect as well. For many, many databases, the special features of foreign keys, stored procedures, etc. are not required. I have worked extensively with Oracle databases in the past, so I am well aware of the advantanges of these advanced features. However, in my current company, there has been no need. Most of our databases, while large, consist of a very small number of tables. The vast majority of our searches are performed on a single table, and these searches are completely optimized for speed. Stored procedures will not help in these scenarios, and foreign keys are not needed. I imagine there are a lot of web sites and applications that have the same characteristics.

      I will not deny that the Windows support is huge, but it is not the only factor in MySQL's court. Speed is a huge issue, especially in the database world.

      • Re:Windows support (Score:3, Insightful)

        by aralin ( 107264 )
        I will not deny that the Windows support is huge, but it is not the only factor in MySQL's court. Speed is a huge issue, especially in the database world.

        I can agree with you, if you want to get a lousy job done fast, then MySQL is exactly that type of DBMS you pick. I mean, if you have few, mostly not conflicting, updates and mostly just need fast query, you will be fine.

        On the other hand, if you want a full scale, acid compliant, transaction oriented DBMS, and your priority is many updates and fewer

      • Re:Windows support (Score:4, Informative)

        by sqlgeek ( 168433 ) on Tuesday August 10, 2004 @03:06PM (#9932575)
        I regret to inform you that MySQL is actually not faster than Oracle.

        MySQL cannot partition data and then either: 1. eliminate partitions and only perform i/o on the relevant one(s), 2. process against all partitions in parallel.

        MySQL cannot maintain aggregated images of your data an re-write ad-hoc queries to use the aggregates.

        MySQL cannot store metadata that will tell it that postal code implies county, and hence a query that wants data aggregated to the county can use the image of data at postal code granularity. (It is not true that postal code implies county, but you get my point).

        MySQL cannot perform an efficient hash-join to save its life (even though a properly designed hash join is mathematically superior in a great many cases) -- and so it falls back on sort-merge regularly.

        MySQL cannot re-write NOT IN or NOT EXISTS clauses as merge anti-joins. Neither can it re-write IN or EXISTS clauses as merge outer-joins.

        I have to get back to work now, but surely you get the idea.

        Cheers,
        Scott

      • Re:Windows support (Score:3, Insightful)

        by johnnyb ( 4816 )
        If your main concern is speed you should not be using a relational database. If your main concern is data integrity, you should not be using MySQL.

    • Re:Windows support (Score:3, Insightful)

      by GooberToo ( 74388 )
      PostgreSQL has always been ahead of MySQL in terms of everything but speed.

      That blanket statement is simply not true. Most people think that a single user with a single query is a measure of speed. For most applications, it is not. And bluntly, this is exactly where MySQL's performance advantage starts and stops. MySQL simply does not scale nearly as well as just about any other RDBMS you'll find, including PostgreSQL.

      Granted, there are still some corner cases where I'm sure MySQL is faster, especial

  • what about distributed transactions? (Score:3, Interesting)

    by RelliK ( 4466 ) on Tuesday August 10, 2004 @12:19PM (#9930440)
    As far as I'm concerned, the only truly missing feature is distributed transactions. Are there any plans to add them any time soon?
    • There have been attempts at adding 2 phase commit which would work with Java applications -- these were deemed incomplete, unsafe or needing work.

      It is likely work will continue on this feature, though don't expect a replication system to be based on this as there are a number of problems within the spec itself (failure modes that leave the system essentially out of order).

      See the pgsql-hackers archives (Google Groups) for details.
      • The way I understand it, someone has been maintaining a 2PC patch (perhaps even since the 7.3.x days?) However, there seems to be little interest in the patch. It didn't get reviewed for long. And finally, when it's about to be integrated in the later phase of going to 8.0, the nested transaction patch got in. This conflicts heavily with 2PC. The 2PC patch maintainer didn't have time to adjust the patch, and so 2PC didn't make it to 8.0. Instead, nested transaction does.

        2PC will probably be integrated in 8

    • Re:what about distributed transactions? (Score:4, Informative)

      by GooberToo ( 74388 ) on Tuesday August 10, 2004 @01:36PM (#9931448)
      As far as I'm concerned, the only truly missing feature is distributed transactions. Are there any plans to add them any time soon?

      Yes. IIRC, in the last release, the protocol has been expanded to allow for this concept. Nested transactions were also required. These are now in place. I'd guess that two phase commits and distributed transactions (sometime after 2pc) will follow sometime after the 8.0 series stablizes.

      In other words, it's on their radar but I don't know what priority they are placing on it.

  • Some nice performance enhancements (Score:5, Interesting)

    by grunt107 ( 739510 ) on Tuesday August 10, 2004 @12:19PM (#9930446)
    The cross-datatype comparison indexing is very important (ex. '1' = 1), as well as index usage on OR clauses. Both of these before would cause full table scans, which is very costly on VLDBs (Very Large DataBases).
    The improvement to the VACUUM I/O processor is important for Postgre to be used on a multi-app server. The 'play nice' feature will allow one server to house the DB AND web servers (albeit at a performance hit to the DB processes).
    Overall, a nice improvement.
  • Why the red wheelbarrow ?

    Shouldn't it be an Elephant, nickname Slonik (Russian for small elephant)
  • Although it's not a Postgres issue, I'd like to see better support for it in Webmin. I know phppgadmin exists, but I prefer doing the simple stuff in Webmin, and there are numerous times I've tutted, and clicked, because the Webmin module doesn't let you do it, whereas the MySQL module does.
    (Can't think of any right now, but there are things...)
  • Tablespaces are nice, but they really need to create database files that can contain objects. This is a major feature that most of the big boys have.

    That is you allocate one file to a certain size. The file is a collection of database pages. Each page can be used by a table or index to store data.

    This makes for much faster backups, and management. I can detach a database, copy the file somewhere, and reattach. There is a lot less file overhead since you lock on to a few files, versus a different file for

  • P.I.T.R (Score:3, Interesting)

    by blooba ( 792259 ) on Tuesday August 10, 2004 @01:31PM (#9931367)
    Point-In-Time Recovery is extremely important, and was the one major factor that prevented me from seriously considering PostgreSQL in a production environment. However, please bear in mind that such a feature requires extensive testing, i.e., crashing your db in every conceivable way, and then recovering it quickly AND consistently (in consistent mode.) So I will still wait and see about this feature.

    Tablespaces are also a key feature. The nicest thing about tablespaces is: each schema can have its own tablespace. This makes maintenance much, much easier, allowing you to isolate the data for each of multiple applications or developers. You can also use it to isolate mission-critical data within the same schema, which in many cases can keep your app running, even if you lose a non-critical portion of your database.

    Savepoints are nice, but I've never had to use them. And altering column data types is nifty, but not really useful in the real world.

    Btw, does PostgreSQL have row-level locking yet?

    • Re:P.I.T.R (Score:5, Informative)

      by GooberToo ( 74388 ) on Tuesday August 10, 2004 @01:52PM (#9931670)
      Btw, does PostgreSQL have row-level locking yet?

      Static docs provide your answers. [postgresql.org]

      Remember, one of the points of using MVCC is to avoid row locking whenever possible. But, I think you'll be hard pressed to come up with a situation where your desired locking facilities are not provided for with PostgreSQL.

      To quote the online documentation:
      "In addition to table-level locks, there are row-level locks. A row-level lock on a specific row is automatically acquired when the row is updated (or deleted or marked for update). The lock is held until the transaction commits or rolls back. Row-level locks do not affect data querying; they block writers to the same row only."

  • Really cool stuff in PostgreSQL (Score:5, Informative)

    by cmowire ( 254489 ) on Tuesday August 10, 2004 @01:41PM (#9931513) Homepage
    • user defined types [postgresql.org], including the ability to create customized indicies [sai.msu.su] for them. So there's a type specifically to handle encrypted authentication passwords, for example, so you don't need to mess with crypt() all of the time.
    • Inheritance for tables, so you can agregate different types of data without needing to explicitly set all kinds of primary keys.
    • Full ACID support, like a real database
    • MVCC [postgresql.org] instead of row or table locking.
    • BSD license
    • Inheritance for tables, so you can agregate different types of data without needing to explicitly set all kinds of primary keys.

      Unfortunately, the inheritance doesn't currently handle things like pks and unique indexes across the inherited tables. sigh.

  • Windows Native Support (Score:5, Interesting)

    by adolfojp ( 730818 ) on Tuesday August 10, 2004 @03:29PM (#9932799)
    I believe that native windows support for PostgreSQL is essential, not necesarily to deploy apps in that enviroment but to test and develop them. When I started using MySQL on my windows box, I had also looked into PostgreSQL. The lack of windows binaries for PostgreSQL made MySQL the default choice for me. On features alone PostgreSQL wins hand down. Also, in my experience, the faster performance of MySQL over PostgreSQL dissapears when I use InnoDB tables for transactional data processing. The doors to PostgreSQL have been open to many developers stuck in the windows world. Perhaps I will try PostgreSQL for my ASP.NET apps in addition to my trusty MySQL.

    Cheers
    Adolfo

Slashdot Top Deals

Anyone can make an omelet with eggs. The trick is to make one with none.

Close