Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 9.4 Released

postgresql.org

Post reply on HN
Print view View original

141–150 of 189 posts

Re: PostgreSQL 9.4 Released

#141

Post by veidr »

squeaky-clean wrote: post #139
veidr wrote: post #126

Earlier quoted context omitted.

That is, btw, an absolutely fantastic distant future sci-fi novel. Among the best of all time. (Vinge doesn't consistently product books that good, but man that one is great.)

Just bought it because that premise sounds amazing. Amazon has it listed as "Zones of Thought series Book 2". Should I read book 1 before reading this?

Maybe, but I don't think you necessarily need to. I started with A Deepness in the Sky and then read the other two (and then all the other books Vinge has written).

Especially since it is actually a prequel, I don't think the order is that important.

Re: PostgreSQL 9.4 Released

#142

Post by ak4g »

qooleot wrote: post #121
masklinn wrote: post #60

Earlier quoted context omitted.

RFC4627 §2.2 ¶1 > The names within an object SHOULD be unique. RFC2119 §3 > [SHOULD], or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Not allowing duplicate keys in JSON objects is very close the exact opposite of a gotcha. Allowing and…

No, it can be a gotcha because the json column type (which still exists and many may mistakenly use instead of the jsonb type) allows it: select '{"foo": 1, "foo": 2}'::json; json ---------------------- {"foo": 1, "foo": 2} (1 row) select '{"foo": 1, "foo": 2}'::jsonb; jsonb ------------ {"foo": 2} (1 row) So technically, the gotcha is you have to remember to use jsonb instead of json, as well as json having a true "…

the json type just stores the string value passed to it, but only the final value is available to the JSON-aware operators.

  mydb=# select
      ('{"foo": 1, "foo": 2}'::jsonb)->'foo' jsonb_foo,
      ('{"foo": 1, "foo": 2}'::json)->'foo'  json_foo;
  jsonb_foo|2
  json_foo|2

Re: PostgreSQL 9.4 Released

#143

Post by threeseed »

norkakn wrote: post #137
threeseed wrote: post #127

Earlier quoted context omitted.

You know what I don't like. People who complain about technologies they've never used. 1. This was NEVER an issue for 99.999% of people. The drivers all had the default set to FSYNC_SAFE. 2. It DOES scale the way it claims. It just doesn't have unlimited scalability and guess what no product does.

2 is wrong. Mongos shits all over itself after only a few nodes and moderate traffic. It's balancing is incredibly broken and will kill a small cluster very quickly. Source: tried to use it at scale

The balancing is broken if you use an inappropriate sharding key. Which is no different to every other system.

And I've used it under very high load with zero problems other than data model changes.

Re: PostgreSQL 9.4 Released

#144

Post by threeseed »

justrudd wrote: post #135
threeseed wrote: post #127

Earlier quoted context omitted.

You know what I don't like. People who complain about technologies they've never used. 1. This was NEVER an issue for 99.999% of people. The drivers all had the default set to FSYNC_SAFE. 2. It DOES scale the way it claims. It just doesn't have unlimited scalability and guess what no product does.

All the drivers default to FSYNC_SAFE? Maybe the Java one didn't get the memo. It's set to ACKNOWLEDGED by default. https://github.com/mongodb/mongo-java-driver/blob/master/src... I like Mongo. And until I really learned about it, I got bitten by the default a few times. Personally I use REPLICA_ACKNOWLEDGED when running in a cluster and FSYNC when writing to a single node.

At the time when the big uproar of the lack of fsyncing by default the Java driver had it set as FSYNC_SAFE (there was no ACKNOWLEDGED).

Re: PostgreSQL 9.4 Released

#145

Post by dmpk2k »

threeseed wrote: post #128
norkakn wrote: post #122

Earlier quoted context omitted.

Clustering is really, really hard. Cassandra is one of the better ones out there, but you have to deal with its data model and weird consistency promises (which however weird you think they are, are weirder) The correct way to cluster also changes dramatically depending on your use case. Sure there are things like RAC that promise to make it just work, but those don't scale more than a few nodes. Mongo is kind of the…

> Cassandra is one of the better ones out there I take it you haven't actually used Cassandra much in the last few years. It's data model is almost identical to a typical relational one and it's consistency promises are quite clear: http://www.datastax.com/documentation/cql/3.0/cql/aboutCQL.h... And I've scaled Cassandra clusters from 1 to 100 nodes in hours with no issues. It really is quite simple. Likewise have ha…

It's quite simple until you write code that has to deal with AP (as in CAP), and the limitations that come with it. I have, and what a pain that was.

Re: PostgreSQL 9.4 Released

#146

Post by amitlan »

internetisthesh wrote: post #97
arthursilva wrote: post #23

Earlier quoted context omitted.

PG has async/sync/hybrid replication for years already. It's not as tooled as MongoDB but there's some tools like http://www.repmgr.org/ to amend it.

Every time I look into tools like this they are quite far behind for example AlwaysOn in MSSQL. For example, with PG I have to reseed the original master if it comes back online after an outage. It's as far as I can tell not fully automatic and transparent to me as the guy responsible for managing it. With SQL and elasticsearch+ZooKeeper for example nodes can go up and down without anyone noticing it and me not havin…

> For example, with PG I have to reseed the original master if it comes back online after an outage

pg_rewind[1] is supposed to fix this. It's moving into core for 9.5, by the way.

[1] https://github.com/vmware/pg_rewind

Re: PostgreSQL 9.4 Released

#147

Post by norkakn »

threeseed wrote: post #143
norkakn wrote: post #137

Earlier quoted context omitted.

2 is wrong. Mongos shits all over itself after only a few nodes and moderate traffic. It's balancing is incredibly broken and will kill a small cluster very quickly. Source: tried to use it at scale

The balancing is broken if you use an inappropriate sharding key. Which is no different to every other system. And I've used it under very high load with zero problems other than data model changes.

I think we had one of the larger mongo installs around, so you just might not have been at the scale to see these issues.

Re: PostgreSQL 9.4 Released

#148

Post by amitlan »

norkakn wrote: post #122
digitalzombie wrote: post #22

Earlier quoted context omitted.

How do you cluster in postgresql? Serious question, my prefer noSQL is cassandra and clustering is pretty easy. I ask this question every year and postgresql have not deliver this. If there is any, there are hardly any documentation on it.

Clustering is really, really hard. Cassandra is one of the better ones out there, but you have to deal with its data model and weird consistency promises (which however weird you think they are, are weirder) The correct way to cluster also changes dramatically depending on your use case. Sure there are things like RAC that promise to make it just work, but those don't scale more than a few nodes. Mongo is kind of the…

> If you have a natural shard key, use a bunch of schemas and table inheritance,

They are working on improving FDW API to help make foreign tables available as inheritance children. I think It's a step forward...

Re: PostgreSQL 9.4 Released

#149

Post by norkakn »

amitlan wrote: post #148
norkakn wrote: post #122

Earlier quoted context omitted.

Clustering is really, really hard. Cassandra is one of the better ones out there, but you have to deal with its data model and weird consistency promises (which however weird you think they are, are weirder) The correct way to cluster also changes dramatically depending on your use case. Sure there are things like RAC that promise to make it just work, but those don't scale more than a few nodes. Mongo is kind of the…

> If you have a natural shard key, use a bunch of schemas and table inheritance, They are working on improving FDW API to help make foreign tables available as inheritance children. I think It's a step forward...

This plus zookeeper to manage shard transitions would be awesome.

Re: PostgreSQL 9.4 Released

#150

Post by jsmeaton »

tracker1 wrote: post #81
atonse wrote: post #11

Great news! I'd love to move over to this from MongoDB for a project that has high uptime requirements. But while I think the JSON will really replace it, does PG have a solution for High Availability (like replica sets) in the works? I'm newer to Postgres so am not sure. Replica Sets are the killer feature for me, more so than just storing JSON documents. I'd appreciate if someone can chime in. I've done some googli…

There are some open-source options, and several closed source options for this... parts are closer to baked in with 9.4, but being realistic, you need to defer to a commercial option. EnterpriseDB pricing for this isn't too bad (about $7k/cpu-socket/year), which is a lot less than MS-SQL, DB2 or Oracle for most uses... but it's imho a feature that should be in the box.

Pricing per socket really really frustrates me. I work in an Oracle shop where we're hamstrung by similar pricing.
Post reply on HN