Live data from Hacker News

PostgreSQL 9.4 Released

postgresql.org

111–120 of 189 posts

Re: PostgreSQL 9.4 Released

#111
post #93

Earlier quoted context omitted.

Only someone with a poor understanding of the industry would think that. Mongo is killing it in the enterprise and their partnerships with Teradata et al is only going to cement their position for likely decades to come. Plus MongoDB's pluggable engine approach will definitely breath some new life into it.

This is exactly right. I can't believe how snide and ignorant a few of the commenters are (except I can because it's the same folks with the same FUD every time). MongoDB isn't standing still and it is getting better and better with every release. Not to mention there are 100's of massive projects running on MongoDB with success. Something about MongoDB really drives the Postgres community (and certain NoSQL DB fans)…

People here have a problem with it because it is a technically poor solution, even among nosql databases. The main problems are:

1. Historically mongodb was distributed with completely unsafe defaults. It was insane to use it with any data you actually cared about. Once you toggle on the safety features most of the vaunted performance goes away.

2. It doesn't actually scale that well despite claims that it does.

The fact that there are better nosql solutions just make people further annoyed. It's basically the cargo cult behaviour of mongodb proponents that people don't like.

Re: PostgreSQL 9.4 Released

#112

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…

Yes and no. There are differences in the data guarantees that something like elastic search and postgresql give. So it's not really appropriate to compare those.

MS SQL does have easier tooling for replication. The setup for postrgresql is complex and it doesn't come with out of the box tools to easily manage failover and recovery as you mention. Progress is being made in making this easier, but it's still mostly in the low level functionality:

https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_...

https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_...

Re: PostgreSQL 9.4 Released

#113

Earlier quoted context omitted.

...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.

Imagine you're an early stage startup. You have a handful of overworked, stressed-out engineers trying to ship v1.0. You don't have the time or resources for a dedicated Ops team, so you go with AWS (I think this is a great use case for AWS or any public cloud, btw--it just makes sense at a really early stage startup).

You ship your product, get some customers. Fast forward 18-24 months. You have grown enormously, you have lots of customers and revenue projections and expectant investors.

Your (now much larger) engineering team has gotten used to AWS conveniences and leveraged a lot of them in the development workflow. Your architecture consists of several layers of ELBs, you have painstakenly set up autoscaling and deployment via Elastic Beanstalk. Your server backups are AMIs. Your data lives in RDS (analytics in Red Shift). Your webservers use Elasticache. SQS is the backbone of your asynchronous job workflow. Customer email traffic goes through SES. Etc.

Now your AWS bill is something like $25-30k/month. You're at the point where the pricing differential between real hardware and AWS is getting big, and it will only get worse over time.

Now management has to make the hard choice:

- Build an Ops team capable of architecting, constructing and deploying new infrastructure on bare metal

- 3-6 months of work to go from design to final cut-over

- Risk some business interruption in the changeover (downtime, unexpected problems) and slower development iteration until the engineering team gets used to new tools/ways of pushing code out.

or

- Continue on AWS and eat the bill as cost of doing business.

This is vendor lock-in at the most basic level.

Re: PostgreSQL 9.4 Released

#114

Earlier quoted context omitted.

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.

It's not something you can assume, but sorting the keys is sometimes a desirable feature in a JSON serializer. (Just like pretty-printing is.)

Re: PostgreSQL 9.4 Released

#115
post #17

Earlier quoted context omitted.

> 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…

Vernor Vinge's A Deepness in the Sky actually has a role described as "programmer archaeologist": http://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstel...

A great book, full of interesting ideas and implications of software development carried on over millennia.

Re: PostgreSQL 9.4 Released

#116
post #17

Earlier quoted context omitted.

> 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 sys…

I like it. It reminds me of something like System Shock (2 is the one I played), where you learn about what happened on this ship before it was overrun by mutants from journals and such. Instead of a book, this may work well as a game of some sort. Perhaps even text-based?

Re: PostgreSQL 9.4 Released

#117
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)".

In Presto, we support the popular but non-standard IF construct as a shorthand for CASE, so you can do this: sum(if(bar, foo))

We also have a count_if() function: count_if(bar)

http://prestodb.io/docs/current/functions/conditional.html#i...

http://prestodb.io/docs/current/functions/aggregate.html#cou...

Re: PostgreSQL 9.4 Released

#118

Earlier quoted context omitted.

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.

Imagine you're an early stage startup. You have a handful of overworked, stressed-out engineers trying to ship v1.0. You don't have the time or resources for a dedicated Ops team, so you go with AWS (I think this is a great use case for AWS or any public cloud, btw--it just makes sense at a really early stage startup). You ship your product, get some customers. Fast forward 18-24 months. You have grown enormously, yo…

Ultimately this is a good problem to have, no? Your startup is alive and growing, you can afford an ops team, your product proved itself. Most startups will have been dead for years at this point.

Re: PostgreSQL 9.4 Released

#119
post #17

Earlier quoted context omitted.

> 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 sys…

This is a really good idea. Too bad I seriously suck at writing fiction or I'd pick this up.

Re: PostgreSQL 9.4 Released

#120
post #17
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…

I'm pretty sure Sony has already optioned this plot and trying to get Tom Cruise for Biff.
Post reply on HN