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

71–80 of 189 posts

Re: PostgreSQL 9.4 Released

#71

Post by tracker1 »

Just want to say to the PostgreSQL and EnterpriseDB guys that it's always great to see the progress on this. My hopes for 9.5/10 is that we will see PLV8 and Replication baked into the actual release.

PLV8 is such a natural fit with the new JSON(B) types that it's probably going to become the most used extension with that data type... And imho sorely missing from the out of the box experience. I'm glad that they've concentrated on getting the data structure and storage right first. Hopefully we'll see this in vNext.

As to replication, I understand that this is part of EnterpriseDB's business model, just the same not having the basic replication pieces baked in, is still lacking compared to other databases. Even if the graphical tooling was commercial only, and all the knob frobbing via config or command line is more complex, having it in the box is a must imho. I actually really like how MongoDB handles their replica sets, and where RethinkDB is going with this as well. Though they aren't transactional SQL databases primarily, it's a must have feature these days. Replication with automagic failover is a feature that has gone past enterprise-only.

One last piece, would be if there were built in functions similar to the String.prototype.normalize that was added to JavaScript... so that input strings could be normalized easier for comparison/indexing, though PLV8 support could/would bring this readily.

All the same, thanks for all of your hard work, and I look forward to the future of PostgreSQL.

Re: PostgreSQL 9.4 Released

#72

Post by correctdarecord »

bkeroack wrote: post #65
joevandyk wrote: post #57

Earlier quoted context omitted.

That performs decently now? I got scared off using EBS a few years ago and use only the ephemeral storage + failovers.

Regardless of whether they're backed by SSD, all EBS volumes on an instance sit behind a 1 Gbps pipe (except for the more exotic and expensive instance types). That's part of the reason why Amazon talks about IOPs instead of raw disk bandwidth. Go ahead and run: $ sudo du -hs /* ..on a vanilla m3.* instance and run iotop in a different session. You'll see bandwidth numbers that 2002 would be embarrassed about.

Bandwidth available for EBS volumes varies. For instance, with EBS-optimized volumes it can be 500Mbps, 1Gbps, 2Gbps, or 10Gbps, depending on the instance type, as shown in this chart from an Amazon presentation:

http://cl.ly/image/440b142t0T1x/Screen%20Shot%202014-12-18%2...

The "NA" of the 8xlarge instance types is because there's no ebs-optimization as an optional feature on that instance type; you automatically get access to 10Gbps.

Here's a video of the whole talk: https://www.youtube.com/watch?v=3OH4-Hx3tlE

Here's the slides: http://www.slideshare.net/AmazonWebServices/stg302-28617072

Re: PostgreSQL 9.4 Released

#73

Post by tracker1 »

masklinn wrote: post #60
qooleot wrote: post #44

Earlier quoted context omitted.

Since you're planning on doing some conceptual work with JSONB, just a heads upon one gotcha - duplicate properties are not allowed. I.E.: { task: "do stuff", task: "do other stuff" } which sometimes is useful when you have front-end data with an N-number of entries but its a form that serializes to an object instead of an array. There are other use cases too.

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…

Most implementations that allow them, from those I've seen only take the last (in actual order) value...

Re: PostgreSQL 9.4 Released

#75

Post by dahdum »

bkeroack wrote: post #66
gfodor wrote: post #54

Earlier quoted context omitted.

The answer is simple, as with any AWS service, a whole slew of concerns (but not all of them) become Not My Problem. I have enough problems.

...in exchange for a number of different problems including (in no particular order): severe vendor lock-in, mediocre to acceptable performance, and relatively high cost per unit of performance.

Different problems, but vendor lock-in isn't really one of them imho. If you are skilled enough to setup pg instead of using RDS you can always move off it to systems under your control.

If you don't have the skills, you can migrate to another provider like Heroku.

As far as my experience, they aren't extending PG in non-compatible ways.

Re: PostgreSQL 9.4 Released

#76

Post by bonif »

nemo44x wrote: post #42
throwaway90446 wrote: post #31

Earlier quoted context omitted.

Just do vnode-based consistent hashing on the client side.

How do I add and remove capacity then?

You don't need to (and if you ever do, you will have or recruit the know-how)

http://www.ovh.com/us/dedicated-servers/big-data/

Re: PostgreSQL 9.4 Released

#77

Post by tracker1 »

wvenable wrote: post #37
jeltz wrote: post #19

Looking forward to when we move to 9.4 so I can start using "sum(foo) FILTER (WHERE bar)" instead of the ugly "sum(CASE WHEN bar THEN foo END)".

Wow, that's fantastic. My queries are littered with that type of construct. Unfortunately, we are using SQL Server and Microsoft hardly ever makes any developer-friendly enhancements to T-SQL.

True enough... I can't even begin to wrap my head around the XML wrangling functions in T-SQL, I feel like a n00b copying JS methods for jQuery when I go there. That said, it's probably one of the easiest RDBMS servers to administrate for small-medium sized deployments.

Re: PostgreSQL 9.4 Released

#78

Post by dahdum »

gtaylor wrote: post #50
dilap wrote: post #28

Earlier quoted context omitted.

Outside observer: Man, I figure setting up a "decently performing" Postgres instance on AWS would be such a common thing to do that it would either be known to be impossible, or have cookie-cutter instructions, if not a script. How is it that it's "difficult and annoying" still? Not trolling, genuinely curious :)

It's not just the setup. For smaller companies with tiny ops teams (or a developer that also serves as an ops guy), RDS can save a bunch of time in maintenance/security/upgrade land. You are going to get decent to good performance for most general cases, and you can easily create failovers and scale up/down without much of any Postgres knowledge. Especially when your product is in "get traction and survive" mode, it'…

Same here, have the skills to run it but not the motivation - rather spend all the time on product dev.

Our one exception was PLV8 support, and RDS added that a couple months ago.

Re: PostgreSQL 9.4 Released

#79

Post by sarciszewski »

wvenable wrote: post #37
jeltz wrote: post #19

Looking forward to when we move to 9.4 so I can start using "sum(foo) FILTER (WHERE bar)" instead of the ugly "sum(CASE WHEN bar THEN foo END)".

Wow, that's fantastic. My queries are littered with that type of construct. Unfortunately, we are using SQL Server and Microsoft hardly ever makes any developer-friendly enhancements to T-SQL.

I've written migration unit testing tools before between SQL Server and PostgreSQL specifically (there are specific gotchas between the two).

If you need help migrating to PGSQL send me an email and I'll help you escape from MSSQHell. :D

Re: PostgreSQL 9.4 Released

#80

Post by organsnyder »

bonif wrote: post #74
organsnyder wrote: post #41

Earlier quoted context omitted.

No.

You're right, lots of amateur-hour developers might still be using mongodb

Yep. MySQL isn't dead yet, either. :-)

I'm not familiar enough with MongoDB (or Postgres 9.4) to really answer the original question. My guess is that Mongo will still be applicable to certain use-cases, but—like you mention—the majority of users will be those who really don't understand the technologies and their strengths/weaknesses.

Post reply on HN