Please create an account to participate in the Slashdot moderation system


Forgot your password?
Databases Cloud Open Source Software Upgrades

PostgreSQL 9.5 Released 104

iamvego writes: Later than the typical release cadence, PostgreSQL 9.5 has finally been released, and brings with it a slew of new features including UPSERT functionality, row-level security, and some big data features (CUBE/ROLLUP, join pushdown for foreign data wrappers, TABLESAMPLE, BRIN indexing and more). The previous release had brought about some new JSON functions and operators, but they only queried the data; 9.5 comes with new operators which now allow modification of JSON values, so it no longer has to be manipulated outside of the database. PostgreSQL's wiki has a more detailed overview of the new features.
This discussion has been archived. No new comments can be posted.

PostgreSQL 9.5 Released

Comments Filter:
  • by Anonymous Coward

    If that is so, Oracle is supporting "bigdata" features since 8i

  • by LWATCDR ( 28044 ) on Thursday January 07, 2016 @01:59PM (#51256731) Homepage Journal

    I have always liked it better than MySQL. Just wish more frameworks and CMSs supported it as the primary database. Support for PostgreSQL always seems like an afterthought.

    • Agreed, though it's most likely because for the vast majority of what a CMS does with a DB, MySQL is Just Good Enough(tm), which is why most CMS users just plop in a MySQL instance (and then promptly ignore it save for the occasional backups).

    • That seems to be changing. Django, for example, supports postgres (and all the cool kids use Django)
    • by Anonymous Coward

      Support for PostgreSQL always seems like an afterthought.

      While the LAMP stack is certainly not dead, I've noticed that new endeavors favor PostgreSQL. One example is Rust; there are over twice as many contributors to Rust support of PostgreSQL than there is for MySQL, and development of the former is far more active.

    • Would anyone care to post links or data comparing the latest MySQL to this new Postgres? I am just about to deploy a new project and this would be the best time to decide. My app uses JPA to access the data base and I don't do anything exotic. So there shouldn't be any coding difference between the two.
  • by Anonymous Coward

    If it's not then I won't use it, won't scale.

    • by Anonymous Coward

      If it's not then I won't use it, won't scale.

      No. PostgreSQL doesn't really scale. It doesn't do active-active shared-storage clusters. It fakes "clusters" with replication - which emphatically does NOT scale.

      For what it does, though? It does it very well and makes MySQL/MariaDB look like what it is - crap.

      • Postgesql can't reliably replicate with slony. Mysql makes it the only option for many cases

        • Re: (Score:3, Informative)

          by Anonymous Coward

          slony is the oldest replication option for postgresql but it is also one of the worst.
          For a hot standby use the builtin Streaming Binary replication
          For a multi-master setup use BRD
          For a master slave with select queries balancing setup Pgpool-II

      • The term "cluster" in generic SQL terms regards having more than database managed by an SQL DBMS. Merely having more than one database in a PostgreSQL install is a "cluster".

        I assume you're referring to "sharding" and conflating it with Oracle's vendor-specific RAC (or something similar) as "clustering"? There's nothing stopping you from using something like pg_shard and/or the CitusDB fork to treat multiple installs as a single logical database. There are other solutions, some open-source and some propriet

        • I assume you're referring to "sharding" and conflating it with Oracle's vendor-specific RAC (or something similar) as "clustering"?

          Don't you know? Shards are the secret ingredient in the web scale sauce. ;)

    • by Tablizer ( 95088 )

      I don't get it, there's probably like only 30 companies in the US big enough to need "web scale". Why does everyone talk about it as if the chance of being or becoming one of those big-wigs is quite small?

      It's like building a parking garage for all your future beemers when you are still a mom-and-pop shop. Is it an ego thing?

      There's usually trade-offs on data tools such that having potential scalability will create here-and-now difficulties when small. I'm skeptical of anybody claiming a free trade-off lunc

      • by Tablizer ( 95088 )


        Re: Why does everyone talk about it as if the chance of being or becoming one of those big-wigs is quite small?

        Rework: Why does everyone talk about it when the chance of being or becoming one of those big-wigs is quite small?

        • Well, being able to scale horizontally is still useful even if you're a small player. Just being able to fire up a second database host and automatically scale up is wonderful for the few times you're actually running out of capacity. Being able to scale up with little effort doesn't mean that you have to scale up big.
          • by Tablizer ( 95088 )

            May I ask for a realistic scenario?

            • You run out of capacity on the database server. You set up another one and now you have two. Problem solved. I see it all the time. They have lots of load balanced web servers handling all the front end traffic, but just one monolithic database server in the back that is holding everything back.
              • by Tablizer ( 95088 )

                Can't the traditional RDBMS shops buy a new bigger data disk, copy the data files over, and change the paths in the config? True, you probably have to take the DB down during this, but it doesn't seem like a huge effort.

                I'm still not seeing it unless something akin to hot-swap is needed.

                Maybe those shops failed to partition the data disk separate from the software disk. That's bad planning, not a bad DB system.

      • I don't know exactly how big 'web scale' is, but I do know several companies who are not in the fortune 1000 that have petabytes of data.....
        If you're trying to keep analytics of everything users do (for advertising, of course), then it can add up quickly.....
    • How about this [] and this [] ?
  • What I really would have liked to see is support for merge. MERGE is already supported by all of the platforms I care about. I don't even care about tradeoffs and syntax of 'UPSERT' schemes all I care about is one thing working across the board and MERGE is currently the closest to that.

  • by shocking ( 55189 ) on Thursday January 07, 2016 @04:59PM (#51258095)

    I'm logging around 500,000 position reports for aircraft each day, which are naturally ordered by time (I also index on the ICAO24 airframe number). A lot of the queries I do involve the timestamps, which of course are only moving in one direction during the course of the day.

    • by swilver ( 617741 )

      Just wondering, do you have a clustered index on the timestamps already?

      • by shocking ( 55189 )

        Nope - this has been my 1st time with Postgres/PostGIS and I did the bare minimum to get it running. There's also a GIST index on the location field. I'm logging between 400000-550000 position reports a day.

    • by Xtifr ( 1323 )

      Yeah, early reports described BRIN as "a niche feature", and my reaction was, well, yeah, broadly speaking, but boy that's a huge niche! :)

  • Skip Locked (Score:4, Insightful)

    by djbckr ( 673156 ) on Thursday January 07, 2016 @08:54PM (#51259403)
    I noticed one feature that will be extremely useful for managing queues is the SKIP LOCKED [] feature. I'm very pleased this made it into the release. I'll be testing performance on this.

(null cookie; hope that's ok)