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

 



Forgot your password?
typodupeerror
×

PostgreSQL 8.1 Available 261

atani writes "PostgreSQL 8.1 has been posted, though not officially announced as of this moment. This release includes two-phased commits, improved SMP and overall performance, a new role system replaces the older user/group, autovacuum is now within the backend rather than a separate contrib module, and various improvements, performance enhancements, and bugfixes. " You can also read the developer notes for the popular database. One thing is clear- with the newest Postresql and MySql, you have much to choose from.
This discussion has been archived. No new comments can be posted.

PostgreSQL 8.1 Available

Comments Filter:
  • by mw ( 16262 ) on Tuesday November 08, 2005 @09:30AM (#13978005)
    I've tested RC1 with some applications, and was really impressed by the bitmap-indices. I hope to see soon a multi-master replication now that 2PC is available. I've heard Slony-2 will have it.
  • by mgkimsal2 ( 200677 ) on Tuesday November 08, 2005 @09:38AM (#13978051) Homepage
    Found it!

    http://www.postgresql.org/ftp/binary/v8.1.0/win32/ [postgresql.org] is the link.

    Clicking the '8.1' link on the 'new releases' section on the front page takes you to the 'source' files only. That was the problem I had!
  • by dpage ( 566064 ) on Tuesday November 08, 2005 @09:43AM (#13978072)
    The URL for the release notes in the story should be: http://www.postgresql.org/docs/8.1/interactive/rel ease.html#RELEASE-8-1 [postgresql.org]
  • Re:Too big? (Score:3, Informative)

    by jocknerd ( 29758 ) on Tuesday November 08, 2005 @09:44AM (#13978075)
    A small website should probably use http://www.sqlite.org/ [sqlite.org]. It doesn't require administration or setup. A complete database is stored in a single file. And it implements most of SQL92. Probably more than MySQL but I'm not positive.
  • RC1/RC2 (Score:5, Informative)

    by PhYrE2k2 ( 806396 ) on Tuesday November 08, 2005 @10:03AM (#13978166)
    Been using RC1/RC2 for some time now. I'm impressed with the role feature, although it won't add much to the average user. The speed has been night and day with 7.3. I also haven't had any problems with the RC's in the slightest except one: a renamed table then wouldn't let me delete the sequence it depended on after the renamed table was deleted. Apparently I wasn't the only one who found it and it has been reported as fixed, though who knows.

    My only beef with PgSQL has been there since before the 7's. There is still no way to not show the list of databases to users who have no right or access to those databases. Why should userA with rights to databaseA see that there is a databaseB or databaseC? This really seems like a simple feature, yet nobody will accept it into the release.

    -M
  • by dpage ( 566064 ) on Tuesday November 08, 2005 @10:07AM (#13978186)
    pgAdmin III bundled tool is 1.4 - I think I was using 1.3 last time I installed. Visually it looks a bit nicer - I'm assuming they've fixed some bugs or something similar to warrant a number change. :)

    1.3 was the development series for 1.4, the new stable release as of yesterday. There are a heap of new features over 1.2 (which shipped with PostgreSQL 8.0) - see http://www.postgresql.org/about/news.419 [postgresql.org] for details.
  • by CyricZ ( 887944 ) on Tuesday November 08, 2005 @10:14AM (#13978239)
    Indeed, SQLite is an excellent choice for small web sites.

    I recently set up a small site for a local business. Basically they wanted to be able to upload and edit product information, in addition to other such tasks.

    Using a combination of OpenBSD, Python and SQLite, it was very easy to get a system set up for them. Best of all for them, it turned an otherwise obsolete computer into a working server.

    Making backups of the database is quite easy too, considering a single file (or three, in their case) can be copied and archived.

    While I did not benchmark the system, there is a good chance that the SQLite solution is far more efficient than that of MySQL, and most likely moreso than PostgreSQL. But then again, SQLite doesn't offer many of the more advanced features of larger database systems. If you don't need those features, you might as well trade them off for faster execution and reduced RAM consumption.

  • by Anonymous Coward on Tuesday November 08, 2005 @10:19AM (#13978265)
    Well there is also the Firebird Superserver. It's a released under a Mozilla license (not affiliated with the mozilla project, of course.) (and a couple other licenses also).

    http://firebird.sourceforge.net/ [sourceforge.net]

    So that's three open source SQL database systems; MySQL, Firebird, and PostgreSQL.

    Here is a comparision between aviable open source relational databases.
    http://www.geocities.com/mailsoftware42/db/ [geocities.com] (it's a bit dated)

    Here is the migration guide for MS-SQL to Firebird, in which I doubt your interested.
    http://firebird.sourceforge.net/manual/migration-m ssql.html [sourceforge.net]
  • by commanderfoxtrot ( 115784 ) on Tuesday November 08, 2005 @10:22AM (#13978291) Homepage
    Indeed- congratulations.

    I'm using PostgreSQL for many things (custom app, Drupal, Apache logging, back-office) and it's great- this new release adds lots of useful bits.

    Probably the most useful new feature for those who use it to run mini web sites will be the MAX() and MIN() functions now using indices- this has been a point of contention for some time.

    XA will be useful for bigger stuff.

    I'm also really pleased auto-vacuum is now part of the DB.

    Now, Gentoo- let's get cracking!
  • Re:Too big? (Score:5, Informative)

    by tezza ( 539307 ) on Tuesday November 08, 2005 @10:28AM (#13978329)
    The parent is a little disingenuous

    sqlite is good. But it does require setup.

    You still need to use CREATE TABLE, INSERTs and the like.

    You need to connect to the thing in your code, with the same attendent problems as other connection strings. sqlite has a poor jdbc element, if java's your gig.

    There are a couple of versions of sqlite. Be aware of this. There is sqlite and sqlite3. Note the jump there from 1 straight to 3. You'll need different DBD drivers there in Perl.

    Also, there is no multiple write capability, so you have to synchrinise on this yourself. Who do you trust to write code for ACID commits? Yourself or say, the Postgres team?.

    Where sqlite rocks is where the data is entirely read only, which eats out Mysqls lunch.

    Also remember that sqlite and Postgres are not mutually exclusive.

    In my sqlite setup, I deploy a sqlite database as a file for the fast read only webservers. Where is this data drawn from? My Postgres database with perl to generate the file. So you can get the UPDATE integrity of Postgres with the blazing speed and compactness of sqlite. This works where your application has discreet state where everything is consistent and you can batch update your sqlite.

  • by Daniel_Staal ( 609844 ) <DStaal@usa.net> on Tuesday November 08, 2005 @10:32AM (#13978352)
    Most handle it by giving you the view of the data before the other user started to modify it. The person who is editing's edits do not show until all of the edit is finished.

    Postgres docs actually have a chapter on this: Concurrency Control [postgresql.org]. Like most high-end databases Postgres can handle this situation in different ways, depending on how it is set up...

    A database should never tell you that the data is not avalible. It should always give you the best version of the data it has.
  • by Anonymous Coward on Tuesday November 08, 2005 @10:32AM (#13978361)
    PostgreSQL has multi master replication, take a look at PGCluster.
  • Re:RC1/RC2 (Score:2, Informative)

    by chriskl ( 231203 ) on Tuesday November 08, 2005 @10:39AM (#13978398)
    No, it's mind-numbingly complicated. If it was easy, it'd have been done by now.

    Chris
  • by Anonymous Coward on Tuesday November 08, 2005 @10:59AM (#13978553)
    We've been using RC1 as well; and regarding mult-master, we've been using PGPool which acts as a 'lite' clustering solution that load balances reads but sends writes to each postgresql server in the cluster.

    For real multi-master clustering, I think there are commercial options availabile; but yes, it'll be nice when it's included.

  • Re:Embedded version? (Score:2, Informative)

    by Anonymous Coward on Tuesday November 08, 2005 @11:10AM (#13978645)
    You should look into Firebird [firebirdsql.org] or Ingres [ca.com] for an embedded relational database.
  • Re:RC1/RC2 (Score:1, Informative)

    by Anonymous Coward on Tuesday November 08, 2005 @11:17AM (#13978708)
    Why should userA with rights to databaseA see that there is a databaseB or databaseC? This really seems like a simple feature, yet nobody will accept it into the release.

    If I understand the talk on the postgresql archvies, you have the SQL Standard to thank for that when they defined how the INFORMATION_SCHEMA works. For almost everything the PostgreSQL team defers to the standard for questions of what will be accepted or not. If you can get the SQL-201X standard to support alternative definitions for the INFORMATION_SCHEMA views, I'm sure the postgresql community will accept your changes.

  • by namekuseijin ( 604504 ) on Tuesday November 08, 2005 @11:41AM (#13978913)
    there's also:
    http://firebird.sourceforge.net/ [sourceforge.net]

    Firebird is kind of a bastard step brother of PostgreSQL, since they share the common Ingres heritage... it's got foreign keys, triggers and stored procedures for far longer than MySQL, for instance. It's Borland Delphi's Interbase code gone open-source. However, it's a relative newcomer and most who care are Delphi developers.

    Its license is neither BSD nor GNU, which i think also makes up for some caution people have against it.
  • Re:Too big? (Score:1, Informative)

    by Anonymous Coward on Tuesday November 08, 2005 @11:53AM (#13979015)
    Also, there is no multiple write capability, so you have to synchrinise on this yourself. Who do you trust to write code for ACID commits? Yourself or say, the Postgres team?.

    You don't _have_ to make your own concurrent-write implementation. SQLite is already ACID compliant; you'll just have to live with blocking writes, which is perfectly fine for most blogs/home pages and that kind of stuff. ;)

    And for heavy load you'd always pick postgres over mysql. Bad news for poor mysql ab..
  • by Some Random Username ( 873177 ) on Tuesday November 08, 2005 @12:04PM (#13979105) Journal
    Its just not part of the default postgresql install, its 3rd party. Search for pgcluster.
  • by jbellis ( 142590 ) <jonathan@carDEBI ... com minus distro> on Tuesday November 08, 2005 @12:32PM (#13979415) Homepage
    "Yukon," which became Sql Server 2005, was originally targetted for "early 2004"
  • Re:The inherit bug? (Score:3, Informative)

    by cayenne8 ( 626475 ) on Tuesday November 08, 2005 @12:39PM (#13979501) Homepage Journal
    "It is too bad that objects does not work yet"

    "do features like that really get used in the real world?"

    I'm with you on that question. These, well at least Postgres, are Relational Database Management Systems. They're not object databases...and IMHO, it isn't worth messing with them in that fashion. Set it up as a relational database, and let your middle tier deal with the object to relational conversions as needed if you use object oriented programming. If not...then, use an object oriented database...if you can find one that is up to par...which I've not run across yet.

  • by egoots ( 557276 ) on Tuesday November 08, 2005 @01:02PM (#13979730)

    Wooww... This looks more and more like Oracle version 7 released in the early 90's. Oracle has had 2PC (2 Phase Commit) for about 15 years now. Nice catchup

    So has Firebird... See: http://firebird.sourceforge.net/index.php?op=guide &id=ib6_overview [sourceforge.net].

  • Re:The inherit bug? (Score:5, Informative)

    by rycamor ( 194164 ) on Tuesday November 08, 2005 @01:03PM (#13979745)
    For those who really understand relational database design, there is nothing that object inheritance can represent that you can't handle relationally.

    In fact, the PostgreSQL team has been musing for years on whether to drop object inheritance completely, because it just muddies the waters of relational design, and causes implementation details to affect logical design.

    But interestingly, table inheritance has become a solution to a lower-level implementation problem: "horizontal" table partitioning. Using inheritance together with tablespaces (available since 8.0), you can break a large table into multiple subtables, each on a different physical storage device, then make a table that inherits from them all to present unified querying to the whole range of data. This is a *big* advantage for very large databases.
  • by egoots ( 557276 ) on Tuesday November 08, 2005 @01:22PM (#13979931)

    From the Release notes:

    E.1.2. Migration to version 8.1

    A dump/restore using pg_dump is required for those wishing to migrate data from any previous release.

  • by Zeut ( 24694 ) on Tuesday November 08, 2005 @01:56PM (#13980232) Homepage
    With 8.1, autovacuum is integrated into the main backend, it's no longer a external contrib module. This has several benifits. First, it's easier to setup, just uncoment the setting int he postgresql.conf. Also, you can now set vacuum and analyze thresholds as well as vacuum delay settings on a per table basis. This was probably the biggest problem people had with the contrib version. In addition it is more reliable since DB activity data is no longer lost between database restarts. Also, you can now exclude specific tables from being touched by autovacuum.
  • by brennz ( 715237 ) on Tuesday November 08, 2005 @02:08PM (#13980334)
    (Note - some content cross posted from the recent MSSQL2005 posting I made)

    I take issue with the number of tools.

    Postgresql has a great variety of tools, both OSS and commercial that work great. I've been working on an updated list of all the tools. Here are a few of the most popular admin tools:

    PGadminIII
    http://www.sqlmanager.net/products/postgresql/mana [sqlmanager.net] ger [sqlmanager.net]

    DBvisualizer
    http://www.minq.se/products/dbvis/ [www.minq.se] [www.minq.se]

    EMS Postgresql Manager
    http://www.sqlmanager.net/products/postgresql/mana [sqlmanager.net] ger [sqlmanager.net]

    PHPpgadmin
    http://sourceforge.net/projects/phppgadmin [sourceforge.net] [sourceforge.net]

    Sybase Power Designer
    http://www.sybase.com/products/enterprisemodeling/ [sybase.com] powerdesigner [sybase.com]

    ERWIN data modeller
    http://www3.ca.com/Solutions/Product.asp?ID=260 [ca.com] [ca.com]

    CASE Studio 2
    http://www.casestudio.com/enu/default.aspx [casestudio.com] [casestudio.com]

    Postgresql has a vibrant tool community. If you want more info on Postgresql tools see
    http://techdocs.postgresql.org/v2/Guides/PostgreSQ [postgresql.org] L%20GUI%20Tools/document_view [postgresql.org]
  • by team99parody ( 880782 ) on Tuesday November 08, 2005 @02:09PM (#13980348) Homepage
    Using Slony you can do even better, with zero-downtime(!!!).

    • Make your old 8.0 system the master in the Slony replication pool.
    • Set up a slave using 8.1,
    • Wait until the initial sync is done.
    • turn off your 8.0 system and failover to the slave (now running 8.1).
    • Make your new 8.1 system the master.
  • by lorcha ( 464930 ) on Tuesday November 08, 2005 @04:23PM (#13981739)
    For a small website, MySQL is overwhelmingly more popular then Postgres. The reasons for this are:
    1. MySQL is very simple to learn
    2. MySQL is supported by virtually all webhosting companies, whereas you have to look pretty hard to find a host that provides PostgreSQL.
    3. MySQL historically has performed much better than Postgres for both reads and writes. Nowadays, MySQL only outperforms Postgres on reads. So for a website, where most database calls are SELECTs, MySQL will often (but not always) give better performance.
    4. Nearly all blog, forum, photo gallery, etc. packages support MySQL. They do not all support Postgres, but some do.
    Now, of course, Postgres has many advantages over MySQL, but for a small hobby website, you should just use whatever you know best and your host supports and your software supports. The answer is normally MySQL for your type of website.

    Postgres is generally better than MySQL (though MySQL is closing the gap) in terms of SQL standards compliance and RDBMS-type features. If you're implementing a true DB app, you should definitely give PostgreSQL a second look. But for a web forum, stick with MySQL.

    P.S. Did you go to Wisconsin?

  • by lorcha ( 464930 ) on Tuesday November 08, 2005 @04:32PM (#13981864)
    mnovotny writes "Computerworld reports that Microsoft is finally set to release their belated SQL Server 2005. From the article: 'Despite a two-year delay, several users who have tested the software cited the improved performance and new functionality it brings as positive developments that likely will convince them to upgrade soon.' The free version can be downloaded directly from Microsoft."

    When Debian Sarge was finally released, the slashdot writeup went so far to assert that "Hell has officially frozen over!". So the sword cuts both ways.

    Nice kneejerk reaction though, buddy.

  • by kervel ( 179803 ) on Tuesday November 08, 2005 @05:37PM (#13982616)
    A big thanks to the very helpful people on the #postgres irc channel. I have been there several times asking for help, and always i have gotten an excellent, very in-depth answer, for what i tought were quite difficult questions (performance problems, weirdness with inherited tables, or just how to build a query to give you what you want in an efficient way). Thank you !

  • by slamb ( 119285 ) * on Tuesday November 08, 2005 @05:42PM (#13982675) Homepage
    So back to my question, how do existing frontends get around that limitation prior to this very useful feature?

    If I understand your question, you're talking about data entry applications doing a "select ... for update" before making changes, waiting for the user to make them, then doing the update and commit. You want to know how applications avoided the "Modify record" page hang until another user was done prior to NOWAIT.

    This scheme actually isn't that common. You don't want to block read-only operations on user input, and this would do that. Besides, in a web application, you don't even want to keep a database connection between hits. (You have no way of knowing if the user has closed the browser and isn't coming back. Keeping a connection open for an hour just in case is undesirable, to say the least.)

    One way would be to hold a modification lock in an application table or in-memory on the application side. But the most common scheme is called "optimistic locking", which is sort of a misnomer. There's no lock. It works like this:

    When you present the modification page to the user, do a select with all of the columns. Keep two copies - the user's modified version and the original. When making the changes, execute an UPDATE like this:

    update table set col1 = newval1, col2 = newval2 where id = id and col1 = oldval1 and col2 = oldval2;

    If this statement returns a row count of 1, you know that no other changes have been made in this time and you can safely go on. If it returns a row count of 0, the record is missing or changed. Send a "Sorry, another user beat you to it" page back to the user. If you want to get fancy, you can show a three-way diff sort of thing to make their changes anyway.

    In the vast majority of cases, this is totally transparent. Only if two people happen to be updating the same columns of the same record in the same table at the same time do you ever get an error. It's almost as simple as completely ignoring concurrency, and it has much better behavior - the user's change being rejected while they still remember what it was, rather than someone's change being silently clobbered.

  • by Anonymous Coward on Tuesday November 08, 2005 @07:23PM (#13983620)
    Pleeease, what "Ingres heritage" are you talking about? AFAIK, Firebird, better said Interbase, was built completely from scratch as a wholly new architecture at the time.
  • by jadavis ( 473492 ) on Wednesday November 09, 2005 @10:21PM (#13994694)
    Nowadays, MySQL only outperforms Postgres on reads.

    That's certainly not true in the general case. There are many situations in which PostgreSQL will outperform MySQL on reads. Particularly if you need one of PostgreSQL's features to achieve reasonable performance.

With your bare hands?!?

Working...