Forgot your password?
typodupeerror
Databases

PostgreSQL 9.2 Out with Greatly Improved Scalability 146

Posted by Unknown Lamer
from the rev-your-engines dept.
The PostgreSQL project announced the release of PostgreSQL 9.2 today. The headliner: "With the addition of linear scalability to 64 cores, index-only scans and reductions in CPU power consumption, PostgreSQL 9.2 has significantly improved scalability and developer flexibility for the most demanding workloads. ... Up to 350,000 read queries per second (more than 4X faster) ... Index-only scans for data warehousing queries (2–20X faster) ... Up to 14,000 data writes per second (5X faster)" Additionally, there's now a JSON type (including the ability to retrieve row results in JSON directly from the database) ala the XML type (although lacking a broad set of utility functions). Minor, but probably a welcome relief to those who need them, 9.2 adds range restricted types. For the gory details, see the what's new page, or the full release notes.
This discussion has been archived. No new comments can be posted.

PostgreSQL 9.2 Out with Greatly Improved Scalability

Comments Filter:
  • by Anonymous Coward

    From the summary:

    "9.1 adds range restricted types"

    nice proof reading...

    • by Taco Cowboy (5327) on Monday September 10, 2012 @10:48PM (#41295783) Journal

      I've been searching for a comparison chart of various SQLs but all I can find are very very old articles

      There's a database project that I'm working on and I'm choosing which SQL to be employed

      MySQL is obviously not up to par

      I don't know how good PostgreSQL is - so, is there a comparison chart or something that can facilitate us, the one who are going to make purchasing decision, to make one choice over the other?

      Thank you !

      • by rycamor (194164) on Tuesday September 11, 2012 @01:04AM (#41296541)

        Generally there is very little in the sense of logical data manipulation capabilities in which Oracle exceeds PostgreSQL (usually the opposite, actually). The main advantage Oracle has is in the extreme high end of scalability and replication, and that benefit is offset by massive complexity in setup and configuration. Even there, PostgreSQL is closing fast these days, with built-in streaming replication, table partitioning, and all sorts of high-end goodies.

        I do all sorts of PostgreSQL consulting, and you would be surprised at the number of large companies and government organizations considering migration from Oracle to PostgreSQL.

        And if you *really* need PostgreSQL to go into high gear, just pay for the commercial Postgres Plus Advanced Server from EnterpriseDB and you will get a few heavy-duty add-ons, including an Oracle compatiblity layer.

        Also, IMHO one of the really cool things about PostgreSQL is the number of very geeky tools it puts at your disposal, such as a rich library of datatypes and additional features, along with the ability to create your own user-defined datatypes.

        • by serviscope_minor (664417) on Tuesday September 11, 2012 @05:55AM (#41297531) Journal

          and you would be surprised at the number of large companies and government organizations considering migration from Oracle to PostgreSQL.

          Not really.

          I've had no experience with the database end of things, but I've been on the receiving end of some other Oracle "products" at two places I've been. Once you've been Oracled, there is a strong incentive never to go anywhere near them again, no matter how they look on paper.

          When it comes for utter distain and hatred for their customers, Oracle make Sony look like rank ametures.

          As far as Oracle are concerned, the customer is a fool whose sole purpose is to be screwed over for as much cash as possible.

      • by F.Ultra (1673484)
        Why is MySQL _obviously_ not up to par? Yes I'm really curios.
        • by Anonymous Coward

          Their developers suck. Go look at the sort of bugs MySQL gets, AND gets AGAIN.

          MySQL is the PHP of databases.

          Example: http://bugs.mysql.com/bug.php?id=31001 [mysql.com]

          Notice the part where the bug is reintroduced. If they require regression tests to pass before releases this bug would not happen again.

          • by Lennie (16154)

            Lots of people such, but it is just hard to trust your data to MySQL. Just a moment ago I posted a link above to this video which illustrates it:

            http://www.youtube.com/watch?v=1PoFIohBSM4 [youtube.com]

            • by tobiasly (524456)

              Lots of people such, but it is just hard to trust your data to MySQL. Just a moment ago I posted a link above to this video which illustrates it:

              http://www.youtube.com/watch?v=1PoFIohBSM4 [youtube.com]

              The person narrating that video sounds so much like Mr. Garrison I couldn't make it past the first minute. However the video is based largely off the info found here:

              http://sql-info.de/mysql/gotchas.html [sql-info.de]

              • by Lennie (16154)

                Yes, I missed that link the first time I watched it, thanks.

                In the comments it says:

                "the vast majority of these gotchas have been solved with SQL_MODE in MySQL 5.0. The SQL_MODE must be set in your configuration file once in then you're done."

                So that's also interresting to know.

          • by F.Ultra (1673484)
            If you read the bug that you linked to you'll see that it was a regression that wasn't catched by the original test, i.e it was probably not a regression after all, simply that the first fix wasn't a fix for all possible cases. And it's not like there has never been any bugs or regression bugs in other dbs...
        • by Nivag064 (904744)
          performance, reliability, ease of development...

          see http://www.postgresql.org/ [postgresql.org]

          PostgreSQL has had ACID compliance built in from the beginning. MySQL added it much later.

          Over the last 18 years I have 3 times gone searching on the Internet for comparisons - each time PostgreSQL came out better than MySQL!

          PostgreSQL is more standards compliant than MySQL, and has far fewer gotchas (unintended consequences of doing something that seemed so straightforward).

          I have the misfortune to have a client with a
          • by F.Ultra (1673484)
            Exactly why does it matter that MySQL got ACID first with the inclusion of InnoDB? It would only matter if you pretend that MySQL version 1.0 is the only version that you can run or something...
            And yeah comparisons on the Internet is of course always true :-), whell it might be that PostgreSQL is better performant etc. It just happens that for my use case it doesn't, we provide stock market data to sql-servers among other things and the only users we have that never experience performance problems or stab
      • by Lennie (16154)

        MySQL has some nice replication built in I believe, I've never used them.

        Other than that, I would thread lightly with MySQL:

        "Why not MySQL"

        http://www.youtube.com/watch?v=1PoFIohBSM4 [youtube.com]

        • by F.Ultra (1673484)
          Very nice of the PostgreSQL developer there to run MySQL in a non strict mode and then play confused when it does exactly what he tells it to do... Perhaps it's unknown to many people, but with MySQL you can configure the database engine for different levels of SQL correctness, the default is usually to be very lenient since that is what the normal PHP user would expect (and people used to the older MyISAM storage engine). But for those who want correct SQL correctness like PostgreSQL it is possible to conf
  • by Mitchell314 (1576581) on Monday September 10, 2012 @08:19PM (#41294749)
    When are they going to come out with the feature where it installs on OS X without requiring a human sacrifice? :P
    • by Anonymous Coward on Monday September 10, 2012 @08:31PM (#41294845)

      9.3. Seriously.

      http://rhaas.blogspot.com/2012/06/absurd-shared-memory-limits.html

      • by Above (100351)

        What a seriously sensible and simple solution. If I could mod up, I would, but I can't so I will reply.

      • by dragonk (140807) on Monday September 10, 2012 @09:17PM (#41295241) Homepage

        I just posted this to the blog, but I will repeat it here --

        There is a very good reason we OS vendors do not ship with SysV default limits high enough to run a serious PostgreSQL database. There is very little software that uses SysV in any serious way other than PostgreSQL and there is a fixed overhead to increasing those limits. You end up wasting RAM for all the users who do not need the limits to be that high. That said, you are late to the party here, vendors have finally decided that the fixed overheads are low enough relative to modern RAM sizes that the defaults can be raised quite high, DragonFly BSD has shipped with greatly increased limits for a year or so and I believe FreeBSD also.

        There is a serious problem with this patch on BSD kernels. All of the BSD sysv implementations have a shm_use_phys optimization which forces the kernel to wire up memory pages used to back SysV segments. This increases performance by not requiring the allocation of pv entries for these pages and also reduces memory pressure. Most serious users of PostgreSQL on BSD platforms use this well-documented optimization. After switching to 9.3, large and well optimized Pg installations that previously ran well in memory will be forced into swap because of the pv entry overhead.

        • by schmiddy (599730) on Tuesday September 11, 2012 @01:02AM (#41296533) Homepage Journal

          There is a serious problem with this patch on BSD kernels. All of the BSD sysv implementations have a shm_use_phys optimization which forces the kernel to wire up memory pages used to back SysV segments. This increases performance by not requiring the allocation of pv entries for these pages and also reduces memory pressure. Most serious users of PostgreSQL on BSD platforms use this well-documented optimization. After switching to 9.3, large and well optimized Pg installations that previously ran well in memory will be forced into swap because of the pv entry overhead.

          I don't see your comment on the blog (maybe it has to be approved?), but the same issue was raised here [nabble.com] during review of the patch. The concern was mostly blown off (most PG developers use Linux instead of BSD, that might well be part of it), but if you had some numbers to back up your post, the -hackers list would definitely be interested. Ideally, you could give numbers and a repeatable benchmark showing a deterioration of 9.3-post-patch vs. 9.3-pre-patch on a BSD. If that's too much work, just the numbers from a dumb C program reading/writing shared memory with mmap() vs. SysV would be a good discussion basis.

      • by m.dillon (147925)

        Here's the problem in a nutshell... any memory mapping that is NOT a sysv shm mapping with the use_phys sysctl set to 1 requires a struct pv_entry for each pte.

        Postgres servers FORK. They are NOT threaded. Each fork attaches (or mmap in the case of this patch) the same shared memory region, but because the processes fork instead of thread each one has a separate pmap for the MMU.

        If you have 60 postgres forked server processes each mapping, say, a 6GB shared memory segment and each trying to fault in the e

    • Re: (Score:3, Informative)

      by Anonymous Coward

      http://postgresapp.com/

  • Range data types (Score:5, Interesting)

    by slack_justyb (862874) on Monday September 10, 2012 @09:41PM (#41295381)
    I think everyone has glossed over the single most important feature in the Postgre SQL that they have refined in this release, IMHO. Ranged data types. Let's say you have a meeting schedule DB application. Well currently if you want to restrict a room between two times (start and stop) so that no one else can have the room during that time, you are going to have to write that logic in your application.

    Postgre's range data type allows you to create unique checks on ranges of time. This can in two lines of code, do every single logic check that is needed to ensure no two people schedule the same room at the same time.

    How this is not showing up on anyone's radar is beyond me, or maybe we all just use Outlook or Google Calendar now. However, the range types are not just limited to the application of time, but of anything that requires uniqueness along a linear fashion, as opposed to just checking to see if any other record matches the one that you are trying to insert.
    • I think everyone has glossed over the single most important feature in the Postgre SQL that they have refined in this release, IMHO. Ranged data types.

      TFS apparently (from the link, which goes to range datatypes) meant to refer to them when it made the comment about "range-restricted datatypes".

  • Postgres-Curious (Score:5, Interesting)

    by kwalker (1383) on Monday September 10, 2012 @09:42PM (#41295397) Journal

    TL;DR: Is there an advanced PostgreSQL for MySQL Users guide out there somewhere? Something more than basic command-line equivalents? And preferably from the last two major releases of the software?

    Long version
    I've been using MySQL personally and professionally for a number of years now. I have setup read-only slaves, reporting servers, multi-master replication, converted between database types, setup hot backups (Regardless of database engine), recovered crashed databases, and I generally know most of the tricks. However I'm not happy with the rumors I'm hearing about Oracle's handling of the software since their acquisition of MySQL's grandparent company, and I'm open to something else if it's more flexible, powerful, and/or efficient.

    I've always heard glowing, wonderful things online about PostgreSQL, but I know no one who knows anything about it, let alone advanced tricks like replication, performance tuning, or showing all the live database connections and operations at the current time. So for any Postgres fans on Slashdot, is there such a thing as a guide to PostgreSQL for MySQL admins, especially with advanced topics like replication, tuning, monitoring, and profiling?

    • by kbahey (102895) on Monday September 10, 2012 @10:22PM (#41295641) Homepage

      Oracle is not that big a of concern.

      There is MariaDB [mariadb.org] which is data-compatible with MySQL, and has some nice additions (like microsecond performance data), and there is also Percona Server [percona.com].

      If Oracle messes up, like they did with OpenOffice, there will be another version that they cannot touch, like LibreOffice.

    • Re:Postgres-Curious (Score:5, Informative)

      by Art3x (973401) on Monday September 10, 2012 @11:14PM (#41295959)

      PostgreSQL replication is new (revision 9.1) so there may be little out there (Yes, there was replication, but with additional software, like Slony).

      I'm in the weird position of having used PostgreSQL mainly --- for seven years, writing dozens of applications --- but never MySQL. I've also used --- out of necessity only --- Microsoft SQL, Oracle, and Ingres, and PostgreSQL is much better. Just from a programming point of view, the syntax is, in my mind, simpler yet more powerful --- more ANSI-SQL-compliant, too, I've heard.

      Anyway, the point is, I've never used anything I like more. I adore PostgreSQL. It's so powerful. So many useful datatypes, functions, syntax. Not to mention it's ACIDity.

      To your question, though --- are there any good books to help a MySQLite move to PostgreSQL? Not that I've come across. But then again, I haven't found any good PostgreSQL books --- or even, for that matter, very well-written SQL books, period. They all are stupefyingly boring --- but I got what I could out of them.

      Actually, PostgreSQL's documentation is not that bad. In particular, try sections I, II, V, VI, and III, in that order. Skip anything that bores you at first. You can always come back. Honestly, there can't be that much of a learning curve for you, coming from MySQL.

      • by poet (8021)

        9.0 was the first version with replication, not 9.1 and we have had things like warm standby since 8.1.

      • by gullevek (174152)

        There are two PostgreSQL books I used a lot in the past: PostgreSQL 9.0 High Performance by Gregory Smith (Packt) and PostgreSQL Second Edition by Douglas Douglas (O'Reilly).

        There is an extended list of books listed on the PostgreSQL homepage: http://www.postgresql.org/docs/books/ [postgresql.org]

        Problem with all books is, they get outdated too quickly. While a lot of the basic info is still true for the books above, the O'Reilly book is very much based on 8.4 with is pretty ancient already. Perhaps getting an ebook is less

      • by aralin (107264)

        If you look for a good SQL programming book, the PL/SQL book from Oracle is the best book written in this area, IMHO. As for the MySQL to PostgreSQL book, there was no incentive to write it for PostgreSQL power users. We mostly looked over the time at MySQL as toy database and it's users as at best misguided and at worst, not caring about data integrity (cardinal sin in my book). So writing such book would be sort of like "Black Hat Hacking for Script Kiddies". Sure it could be done, but who wants a bunch o

        • Re: (Score:3, Informative)

          by fuzzytv (2108482)

          Well, recommending a PL/SQL book as a source for learning SQL is a bit silly IMHO. Moreover, I find the books from Oracle rather bad - there are better sources to learn PL/SQL (e.g. the one from Feuerstein is a much better book).

          And in fact there's a great book about administering PostgreSQL from Hannu Krosing - it's called "PostgreSQL 9 Admin Cookbook" [http://www.packtpub.com/postgresql-9-admin-cookbook/book]. It's a great set of recipes for admins for common tasks, not an exhaustive documentation (that's

          • by aralin (107264)

            I'm not sure if the book available to Oracle employees on PL/SQL is the same as the one available externally, I assume so. The books by Oracle are generally not so good, I'd agree, but the PL/SQL one is a rare gem. It sounds like you read a bunch of Oracle books, but not this one and you recommend what you did read on the subject, which is fine. But in this case ... Anyway....

            What the point was not a good Postgres book, there are some. The point was a comparison book taking you from MySQL to PostgreSQL and

            • by fuzzytv (2108482)

              Not sure which Oracle books you mean - I've read e.g. "PL/SQL Programming" (ISBN 978-0072230666) and "Expert Oracle PL/SQL" (ISBN 978-0072261943) and probably some more when preparing for OCP exams. And I'd definitely recommend ISBN 978-0596514464 instead of the first one. But yeah, it's a matter of opinion.

              But you're right - there are no "PostgreSQL for MySQL people" guides. The problem is that almost no one is able to write it. The people who are switching from MySQL to PostgreSQL don't have the knowledge

      • by omnichad (1198475)

        I have to admit, as a long-time MySQL user, it really messes with your head and makes you not do things in a way that works with MS SQL Server or PostgreSQL. Especially how MySQL does its lazy grouping.

        I've only tried other databases for a short while and give up because I know that I'd have to learn everything properly. If I was starting a brand new project, it might be great, but I wouldn't want to rewrite an existing database app with it.

    • Re:Postgres-Curious (Score:5, Informative)

      by rycamor (194164) on Tuesday September 11, 2012 @01:17AM (#41296595)

      Unfortunately, I haven't found a really good guide of the type you are looking for. I can give you my experiences, going from MySQL to PostgreSQL, back to MySQL to support it at a large company, and then back to PostgreSQL. Generally, these days there is really *nothing* that I can find about MySQL that can't be done better in PostgreSQL. I mean it. At least for awhile MySQL could boast of native replication, but Postgres biw has that and it is arguably much more robust than MySQL's solution (had the misfortune to support MySQL replication for 2 years). Ditto with full-text indexing, and just about any other MySQL feature.

      Main differences:

      1. PostgreSQL is much more "correct" in how it handles data and has very little (essentially no) unpredictable or showstoppingly odd behavior of the sort you find in MySQL all the time. Your main problem in migrating an app to PostgreSQL will be all those corner cases that MySQL just "accepts" when it really shouldn't, such as entering '0000-00-00' into a date field, or allowing every month to have days 0-31. In other words, PostgreSQL forces you to be a lot more careful with your data. Annoying, perhaps, if you are developing a non-mission-critical system like a web CMS or some such, but absolutely a lifesaver if you deal with data where large numbers of dollars and cents (or lives) depend on correct handling.

      MySQL has provided for a fair amount of cleanup for those who enable ANSI standard behavior, but it is still nowhere close to PostgreSQL's level of data integrity enforcement.

      2. MySQL has different table types, each of which support different features. For example, you cannot have full-text indexing in InnoDB (transactional) tables. PostgreSQL has complete internal consistency in this regard.

      3. MySQL has an almost entirely useless error log. PostgreSQL's can be ratcheted up to an excruciating level of detail, depending on what you want to troubleshoot. Ditto with error messages themselves.

      4. MANY MANY more choices in datatypes and functions to manipulate them. Definitely a higher learning curve, but worth it for expressive capability.

      5. Don't get me started on performance. Yes, if you have a few flat tables, MySQL will be faster. Once you start doing anything complicated, you are in for a world of pain. Did you know that MySQL re-compiles every stored procedure in a database on every new connection? PHP websites with per-page-load connections can really suffer.

      6. Don't get the idea that PostgreSQL is more complex to work with. If you want simple, you can stick with the simple parts, but if you want to delve into complex database designs and methodologies, PostgreSQL pretty much opens up the world to you.

      - Glad to be back in the PostgreSQL world...

      • by F.Ultra (1673484)
        >Did you know that MySQL re-compiles every stored procedure in a database on every new connection?
        Actually it really doesn't, it will only recompile the stored procedure if the compiled version has left the cache, so as long as they fit into the cache you would see very little compiling going on.
    • by Jay L (74152)

      Greg Smith's book "High-Performance SQL" is a good start.

    • by fuzzytv (2108482)

      No, I'm not aware of such thing ("PostgreSQL for MySQL people" style guide).

      The best thing you can do is give it a ride - install it, use http://www.postgresql.org/docs/9.1/interactive/admin.html [postgresql.org] to do the setup etc.

      Basically all you need to do to install and start the PostgreSQL from source code is this (at least on Linux):

      $ cd postgresql-9.1.5
      $ ./configure --prefix=/path-to-install
      $ make install
      $ export PATH=/path-to-install/bin:$PATH
      $ pg_ctl -D /database-directory init ... fiddle with the config at /data

    • by Anonymous Coward

      Read the PostgreSQL docs.

      Unlike MySQL, their docs are clear, complete and exhaustive. The MySQL docs require you to read user comments on the documentation to learn how the software actually works.

      Not the case here, PostgreSQL's design and behavior is clearly and properly documentated

  • by Art3x (973401) on Monday September 10, 2012 @11:35PM (#41296069)

    To me, JSON very interesting. I don't know how exactly I'll use it, but it combines all that's great about PostgreSQL with some of what was interesting about CouchDB and other projects like it.

    Mainly, one-to-many relationships may be easier. Usually, they are two separate select statements. For example, one to get the article, another to get the comments. Then you patch it all together in PHP, or whatever middle language you're using. With JSON support, that could be a single SELECT, crammed up in JSON, which you then uncram with a single json_decode function call in PHP, which would yield nice nested arrays.

    • by Anonymous Coward

      I think you just made the database fairies cry.

      • by Anonymous Coward

        Then you defiantly don't want to see the DB tables I've seen with just a primary key and a single XML field, then add on XPath indexes.

    • Mainly, one-to-many relationships may be easier. Usually, they are two separate select statements.For example, one to get the article, another to get the comments. Then you patch it all together in PHP, or whatever middle language you're using.

      I'm not sure adding new SQL features is going to deal with the problem of people not using the features they already have. Its already quite possible in PostgreSQL to do a single select that gets the article data and an aggregate that contains all the comments. Feat

  • by FlyingGuy (989135) <flyingguy.gmail@com> on Tuesday September 11, 2012 @12:25AM (#41296335)

    Until the fix the TX number issue ( the infamous rollover ) then they are pretty much out of the running in DB's that have VERY high insert levels since the vacuum process cannot hope to keep up with tables that have 100's of millions of rows.

    I am an Oracle professional but I do keep track of Postgres and like it, but the 32 bit TX t is a bit of an Achilles heel.

    • by Anonymous Coward

      you can't vacuum your table every 2 billion transactions? did you know autovacuum exists?

      There is no table with "100's of millions of rows" that can't be vacuumed every 2 BILLION transactions.

      http://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

      • by FlyingGuy (989135)
        hmmmm table with 17 trillion rows? Not so much.
        • by Anonymous Coward

          If you have a single table with 17 trillion rows then you're doing it wrong. And inserts aren't really an issue with MVCC in PG - I'd focus more on updates.

          Partitioning in PostgreSQL will let you split that up into separate physical items on disk. As others have said - you just need to let vacuum scan the table once every 2 billion transactions or so to keep things in check. Rows that aren't update regularly will be given the special frozen xid and won't be subject to any wrap around issues.

          And as far as da

          • by rycamor (194164)

            Yes, there are all sorts of interesting strategies you can employ once you separate the physical storage from the logical presentation... can't be said enough.

        • by rtaylor (70602)

          I don't see why not.

          You had the IO to create those 17 trillion tuples in the first place; so vacuum will use that same IO capacity to maintain it.

          The low billions of tuples isn't much of an issue despite being on spinning disk with very little in memory.

    • by LizardKing (5245)

      Until the fix the TX number issue ( the infamous rollover ) then they are pretty much out of the running in DB's that have VERY high insert levels since the vacuum process cannot hope to keep up with tables that have 100's of millions of rows.

      Infamous to whom? A vacuum updates the frozen TID, which is a trivial operation and allows a subsequent TID to safely wrap around. And I'm struggling to think of any common use cases where the volume of inserts is so high that they can't afford a vacuum every two bil

      • by TheLink (130905)

        A vacuum updates the frozen TID, which is a trivial operation and allows a subsequent TID to safely wrap around.

        What if you have at least one outstanding transaction/connection? Can vacuum update the frozen TID then?

        For example if you have a transaction that's open for a few weeks and happen to have 4 billion transactions during that time.

        I believe perl DBI/DBD in AUTOCOMMIT OFF mode starts a new transaction immediately after you commit or rollback. So if you have an application using that library that is idling for weeks a transaction would presumably be open for the entire time- since it would be connected to the d

        • by nullchar (446050)

          A long open transaction (that's used the table in question) will block auto vacuum for those rows.

          You can set options in postgresql.conf to auto-kill long transactions if you like (set a hard limit for transaction time).

          I solved this another way by only examining IDLE transactions via pg_stat_activity. Any long running transactions are left alone, while long idle transactions are killed.

    • by fuzzytv (2108482)

      So you're calling yourself an Oracle professional and you're not aware of this: http://www.infoworld.com/d/security/fundamental-oracle-flaw-revealed-184163-0 [infoworld.com] ?

      I mean - PostgreSQL does have 32 bit transactions IDs and a well designed process to prevent wraparound.

      Oracle has 48bit transaction IDs, a number of bugs that speed up transaction ID growth, a feature that "synchronizes" transaction IDs through the whole cluster (thus the IDs are growing according to the busiest of the instances) and a soft SCN limit

  • It just works properly out of the box. No nasty surprises, no alarming omissions or deviations from expected database behaviour. It's just a fast, reliable database which also happens to be open source and free.

    I'm sure most of this applies to MySQL these days but historically it didn't and I never saw the attraction of a DB which went through a succession of backends in order to obtain the behaviour PostgreSQL always supplied. It doesn't help that MySQL is Oracle owned and all the issues with licencing a

    • by Lennie (16154)

      I believe they both improved.

      PostgreSQL 7.x wasn't as much fun either which didn't have autovacuum and needed a lot of tuning.

      I haven't tried something like Drizzle but it seems they ditched a lot of old code and problems.

      • Yeah, 7.x was no picnic. Especially if you came from a Windows background and needed to install it on a Windows server.

        We didn't switch until 8.0 or 8.1, after we were able to install as a native Windows application and play with it. The pgsql database servers are actually Linux, but we were still feeling our way there as well.
  • by DragonWriter (970822) on Tuesday September 11, 2012 @10:02AM (#41299167)

    Minor, but probably a welcome relief to those who need them, 9.1 adds range restricted types.

    First, its 9.2, not 9.1.

    Second, (as shown in the link) these are range types, not range-restricted types. Range-restricted types (as known from, e.g., Ada) are something that (via domains with check constraints) PostgreSQL has supported for a very long time.

    Range types, combined with 9.2s support for exclusion constraints, are a pretty major new feature that give 9.2 a great facility in dealing with (among other things) temporal data and enforcing common logical constraints on such data in the database as simple-to-express constraints rather than through triggers.

Contemptuous lights flashed flashed across the computer's console. -- Hitchhiker's Guide to the Galaxy

Working...