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

161–170 of 189 posts

Re: PostgreSQL 9.4 Released

#161

Post by dodyg »

zapov wrote: post #156
taspeotis wrote: post #138

It looks like PostgreSQL is on track to slowly succeed MySQL as the de-facto open source database. Microsoft tentatively seems to be settling on them as the preferred RDBMS for non-Windows platforms [1]: > Within ASP.NET 5 our primary focus is on SQL Server, and then PostgreSQL to support the standard Mac/Linux environment. I use EF+SQL Server and they're very much complementary and provide an excellent developer exp…

> At this point I'm convinced only MS know how to write LINQ providers that won't fall over the moment you try to do something useful with them. I would argue Revenj + Postgres provide much better developer experience. But as you said, it's not written by Microsoft so that attitude doesn't help it out. I'm 100% sure Microsoft can't write LINQ provider which actually understands Postgres and can use it to the fullest…

The problem with Revenj is that it seems to tied to dsl-platform, which looks like an online service. People would rather to have their compiler tools with them. You don't want your code investments to go 'poof' should the online service fails.

Re: PostgreSQL 9.4 Released

#162

Post by zapov »

dodyg wrote: post #161
zapov wrote: post #156

Earlier quoted context omitted.

> At this point I'm convinced only MS know how to write LINQ providers that won't fall over the moment you try to do something useful with them. I would argue Revenj + Postgres provide much better developer experience. But as you said, it's not written by Microsoft so that attitude doesn't help it out. I'm 100% sure Microsoft can't write LINQ provider which actually understands Postgres and can use it to the fullest…

The problem with Revenj is that it seems to tied to dsl-platform, which looks like an online service. People would rather to have their compiler tools with them. You don't want your code investments to go 'poof' should the online service fails.

While that's a fair criticism (to have compiler offline), dsl-platform can be licensed for an offline use.

It's not like Revenj needs dsl-platform, but rather that dsl-platform integrates into Revenj.

So to make it blunt, would you try/use Revenj if it had part of dsl-platform compilers available for offline use?

Re: PostgreSQL 9.4 Released

#163

Post by mjevans »

jackmaney wrote: post #136
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.

Okay, I'll bite. What, exactly, do you think should happen if you have an object of the form { task: "do stuff", task: "do other stuff" } ? Objects in JSON are key-value pairs. A single key goes to a single value . Instead, you should map task to an array of values.

No, you should have written an array of values to begin with.

Coercing data types is surely more wrong than taking the most recently supplied value for a given key in a map.

Re: PostgreSQL 9.4 Released

#164

Post by hype_this »

What a joke. There's not even a working MySQL => Postgres 9.4 migration tool that works. Try them.

On paper, Postgres sounds great. But of all the people on here cooing about it, how many are actually using the tool?

I don't know who has the stronger hype machine on Hacker News: Postgres or Rust.

Re: PostgreSQL 9.4 Released

#165

Post by dodyg »

zapov wrote: post #162
dodyg wrote: post #161

Earlier quoted context omitted.

The problem with Revenj is that it seems to tied to dsl-platform, which looks like an online service. People would rather to have their compiler tools with them. You don't want your code investments to go 'poof' should the online service fails.

While that's a fair criticism (to have compiler offline), dsl-platform can be licensed for an offline use. It's not like Revenj needs dsl-platform, but rather that dsl-platform integrates into Revenj. So to make it blunt, would you try/use Revenj if it had part of dsl-platform compilers available for offline use?

It's a surprise to me that RevenJ can be used without dsl-platform because the readme makes it look like it is dependent on dsl-platform.

Yes, i would try dsl-platform if it's available offline. Online compilers are pretty much deal breakers for me.

Re: PostgreSQL 9.4 Released

#166

Post by danmaz74 »

jeffdavis wrote: post #154
danmaz74 wrote: post #101

Earlier quoted context omitted.

+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!

Can the documentation or user experience be improved to prevent that issue from happening to someone else?

There isn't an easy way imho, because this was a real edge case caused by creating a new index while there was an "idle in transaction" connection: http://dba.stackexchange.com/questions/84844/dropped-an-inde...

But more in general, at least in my experience, understanding and optimizing indexes usage is the most important and most difficult task with postgresql, and improving the documentation about this could really help. Usually they work well on their own, but a few times I was really baffled why pg wouldn't use an index which I created to optimize some important and slow query, even if using the index (when I found a way to "convince" pg to do so) cut the execution time by a factor of 100 or even 1000.

The easiest improvement that comes to my mind would be to add to the manual a better and more in-depth explanation about how to optimize index usage; this could include a FAQ where you could also include my edge case. This current page could be a starting point: http://www.postgresql.org/docs/9.3/interactive/indexes-exami...

An even better but much more long term project would be to improve the EXPLAIN ANALYZE commands; specifically it would be great if it could show the different plans considered, making it easy to understand why a specific plan was discarded. Right now, the only way to nudge pg in the right direction is by trial and error. Also making the explain output easier to understand would help, but I guess that's difficult.

Anyway, thanks again for all the effort of the pg contributors!

Re: PostgreSQL 9.4 Released

#167

Post by forgottenpass »

hype_this wrote: post #164

What a joke. There's not even a working MySQL => Postgres 9.4 migration tool that works. Try them. On paper, Postgres sounds great. But of all the people on here cooing about it, how many are actually using the tool? I don't know who has the stronger hype machine on Hacker News: Postgres or Rust.

Just because you haven't used it doesn't put the adoption of postgres on the same level as a still experimental programming language. It's a solid open source solution in the run of the mill domain of RDBMS. It has a weird level of hype these days in certain pockets of the internet as mysql's hayday is long gone, and the whole "no sql" fervor is gone and now understood to have been oversold.

I've worked on projects that were using it a decade ago. To this day at a different job I'm still building on it. Shipping it our products to customers, building internal tools on it, and we've have purchased a handful of self-hosted applications that have happened to run on it.

You're generalizing from your own experience and assuming that's everyone's experience. Availability of dump and load tools to move from mysql don't really that much. MySQL isn't poison just because there is a new hotness. Keeping old shit on mysql, and using postgres for new things is a much more common migration strategy.

Re: PostgreSQL 9.4 Released

#168

Post by pmontra »

norkakn wrote: post #140
pmontra wrote: post #134

Earlier quoted context omitted.

> Mongo is kind of the worst in this - it clusters in one weird way, has bad tooling, and subtly destroys your data at scale. I'm genuinely interested. How does Mongo corrupts data? Thanks.

The most infuriating way is that it will roll back its oplog on an election, and sometimes throw away confirmed writes. Mongos does weird magic as well when it gets confused, and will confirm writes to the wrong shards during "interesting" situations.

This is more than worrysome. I googled for it and found this http://docs.mongodb.org/v2.6/core/replica-set-rollbacks/

Is this behaviour what you are referring to?

> A rollback reverts write operations on a former primary when the member rejoins its replica set after a failover. A rollback is necessary only if the primary had accepted write operations that the secondaries had not successfully replicated before the primary stepped down. When the primary rejoins the set as a secondary, it reverts, or “rolls back,” its write operations to maintain database consistency with the other members.

Re: PostgreSQL 9.4 Released

#169

Post by palmer_eldritch »

tensor wrote: post #111
nemo44x wrote: post #93

Earlier quoted context omitted.

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…

Basically what you're saying is that mongodb is the mysql of nosql databases right?

Re: PostgreSQL 9.4 Released

#170

Post by lucian1900 »

hype_this wrote: post #164

What a joke. There's not even a working MySQL => Postgres 9.4 migration tool that works. Try them. On paper, Postgres sounds great. But of all the people on here cooing about it, how many are actually using the tool? I don't know who has the stronger hype machine on Hacker News: Postgres or Rust.

Both Postgres and Rust are grounded in solid, desirable concepts. That's why people like them.

Of course, they are on two sides of the maturity spectrum. Postgres is used by lots of people and we're happy it works so well. Rust is not even released yet, but looks very promising.

Post reply on HN