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

101–110 of 189 posts

Re: PostgreSQL 9.4 Released

#101

Post by danmaz74 »

pilif wrote: post #5

Like every year before, the Postgres team has blessed us with an early christmas present. And like every release post before, I'd like to use this opportunity to say thanks to the team for the awesome job they are doing year after year. It's not just the database itself (and that's awesome on its own right), but it's also all the peripheral stuff: The documentation is seriously amazing and very complete, the tools th…

+1 for #postgresql help. Recently I had a really weird problem, and after a few hours with forums and manuals I went there to ask for help. They saved me I don't know how many more hours that would almost for sure not found the completely unexpected answer. Thanks!

Re: PostgreSQL 9.4 Released

#102

Post by steventhedev »

matthewrudy wrote: post #14
steventhedev wrote: post #10

Quick question regarding JSONB: Is attribute order stable? Obviously, order is not preserved, but if the order changes on subsequent accesses, this causes problems if you ever serve content directly from a jsonb field without sorting the attributes manually.

According to the json spec "An object is an unordered set of name/value pairs." So you should not be relying on ordering of json fields.

In theory, correct. In practice, here are the two use cases which that approach breaks:

1. Cache control using etags. If the content changes by a single byte, even if semantically identical, the etag should change. Hence '{"foo":1,"bar":2}' is not equivalent to '{"bar":2,"foo":1}'. I can see serving such information directly, or embedding it into a larger JSON response.

2. Committed JSON files. This is an anti-pattern, but one I've seen many times. In one case, it was a translation file that was generated in a separate project. When I joined, it had been like that for more than 5 years. It was like that when I left, although I at least monkey patched REXML to emit sorted attributes in XML (also unordered in theory).

So while in practice, I don't depend on a specific ordering, but I need the order (whatever it is) to be stable. For all I care, it could be sorted by the cryptographic hash of the keys, so long as it is consistent.

Just to gather what others have said here: JSONB appears to store fields sorted lexicographically for binary search purposes, and emits them in that order as well. This could be undocumented behavior, yet important for the above two use cases.

Re: PostgreSQL 9.4 Released

#103

Post by lewaldman »

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.

I really don't get all this yadda yadda about AWS lock-in.

Which component on AWS doesn't have a OpenSource counter-part that you, having the time, knowledge (;P) and time for it, could not implement on your own infrastructure?

Really... It's an honest question from some one that works as Senior AWS architect on a full time job.

Re: PostgreSQL 9.4 Released

#104

Post by correctdarecord »

bkeroack wrote: post #70
personZ wrote: post #69

Earlier quoted context omitted.

I don't personally get the RDS value proposition, but how does it lead to vendor lock-in, much less severe vendor lock-in? I don't believe there is really any lock-in whatsoever -- backup your database and move it wherever you want, whether you're running the pgsql, Mysql, or SQL Server variants of RDS.

While of course you're correct, it's a bit like saying "you can just pack up your code and run it somewhere else". If the entire architecture and workflow are based around proprietary AWS tools (Elastic Beanstalk, Elastic load balancers, RDS, Cloud Formation, autoscaling, etc) even if your code is technically portable, you're still suffering from vendor lock-in. Arguably worse than the bad old days of the Microsoft m…

Where you see 'vendor lock-in', I see the opportunity to leverage somebody else's engineering talent to solve commodity problems that our customers don't pay for.

Re: PostgreSQL 9.4 Released

#105

Post by nemo44x »

gthank wrote: post #88
klaruz wrote: post #59

Earlier quoted context omitted.

I think the problem is clustering is still very much a duct-tape situation in postgresql with no real clear consensus on how to build out a cluster. Postgres-XL looks great for scale out, but you need 4 independent types of servers. Even with all those moving parts, it doesn't provide availability. If you want fail-over, you need pacemaker for the data nodes with traditional sync replication, and something like VRRP…

If you honestly believe that all you have to do is stand up a bunch of instances of Mongo/Cassandra/whatever and you instantly get acceptable HA, then you need to read the [Jepsen series]( https://aphyr.com/tags/jepsen )

It depends on what you consider "acceptable HA". There are many instances where I'm not trying to protect from a network partition (single data center, monitored batch data loads, etc) and don't have a requirement for that level of tolerance. However, you're right in that it's important to know that nearly every distributed system has edge cases where things might not appear as you thought. Elasticsearch has a section on their Website detailing their resiliency efforts. I wish every company was as transparent about what they're doing on that front so we can all plan and consider expectations better.

Re: PostgreSQL 9.4 Released

#106

Post by angersock »

gh02t wrote: post #17
pilif wrote: post #5

Like every year before, the Postgres team has blessed us with an early christmas present. And like every release post before, I'd like to use this opportunity to say thanks to the team for the awesome job they are doing year after year. It's not just the database itself (and that's awesome on its own right), but it's also all the peripheral stuff: The documentation is seriously amazing and very complete, the tools th…

> we'd be in a much better place what code-archaeology is concerned. This sounds like a great setup for a sci-fi novel. 500 years into the future, the infrastructure their distant ancestors coded has begun to fail. Now Biff Miffington, code-archaeologist, must sift through millions of forgotten messages using a mysterious tool remembered only as "git." Its interface is arcane and the remaining messages broken, tainte…

Testing the waters, I'd played with the idea of a story with basically this setup:

Two new developers start at a company/startup, and are brought in to do a six-month sprint to fix a stalled/broken product after the development team becomes unavailable because reasons. So, they're dropped into a codebase and are trying to pull everything together.

However, as they work through into deeper and deeper parts of the system, the commit messages and comments get more and more cryptic and unsettling, hinting at the reasons for the prior team's dissolution, the business forces that caused that to happen, and maybe something worse/better going on outside.

I'm really lazy though. :(

Re: PostgreSQL 9.4 Released

#107

Post by perlgeek »

steventhedev wrote: post #102
matthewrudy wrote: post #14

Earlier quoted context omitted.

According to the json spec "An object is an unordered set of name/value pairs." So you should not be relying on ordering of json fields.

In theory, correct. In practice, here are the two use cases which that approach breaks: 1. Cache control using etags. If the content changes by a single byte, even if semantically identical, the etag should change. Hence '{"foo":1,"bar":2}' is not equivalent to '{"bar":2,"foo":1}'. I can see serving such information directly, or embedding it into a larger JSON response. 2. Committed JSON files. This is an anti-patter…

You can still use the 'json' type (not 'jsonb'), which preserves the text representation.

Or you can sort the keys on serialization when you serve or store the JSON.

Re: PostgreSQL 9.4 Released

#108

Post by bonif »

nemo44x wrote: post #94
bonif wrote: post #76

Earlier quoted context omitted.

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/

That is entirely wrong. It might suit your use case (having a bunch of monkeys running around fixing a hack job) but I'd rather use a tool which can expand and reduce capacity when I want, which is quite often. It saves me money on cloud hosting to only provision what I need when I need it and be able to expand and contract it at will, easily. Your solution fails at this.

This is not my solution (and I don't know much about monkeys, sorry).

This is a cost-effective way to be always maxed out (expanded as you say) with fixed price, this can scale well beyond the needs of almost every business. And , as I said, if you happen to be the next Facebook, Uber, Airbnb or whatever, you will acquire the know-how to scale.

Re: PostgreSQL 9.4 Released

#109

Post by g8oz »

radicalbyte wrote: post #18

Next year I really need to switch from MSSQL to Postgres. The work that the Postgres team have done in the last 2-3 years is really amazing. They are also clearly reaping the benefits of some very smart architectural decisions, and that gives me the confidence that they will be able to continue innovating in the coming years.

If only there were a way to run performant Postgres on Windows. Maybe it's time learn Hyper-V so I can run it in a Linux VM.

Re: PostgreSQL 9.4 Released

#110

Post by lsaferite »

skybrian wrote: post #95
azdle wrote: post #16

Earlier quoted context omitted.

Why would this cause problems? Order is irrelevant in JSON. "An object is an unordered set of name/value pairs."[0] From a there is absolutely no difference between {"name": "Patrick", "age": 24} and {"age": 24, "name": "Patrick"}. [0] http://json.org/ EDIT: Well, now four of us have replied at the same time saying the same thing, I'd say this topic is now well covered.

Sometimes it matters whether serialization to a string is a deterministic function. If the JSON is the same, you want the output to be the same. A JSON parser won't care, but it's useful to do a string comparison without parsing (for example when diffing output).

But that's not really a correct thing to expect is it? If an object is an unordered set of name/value pairs then multiple serialized versions of the object may indeed be the same object data.
Post reply on HN