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

171–180 of 189 posts

Re: PostgreSQL 9.4 Released

#171

Post by lucian1900 »

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…

For the former, you really need to sort the keys. If you ever end up passing the JSON through any other encode/decode step, your ETags will break and it won't be obvious why.

For hand-written JSON, I'm not sure there's a good solution besides modding the users' editors to sort for them.

Re: PostgreSQL 9.4 Released

#173

Post by mc808 »

mjevans wrote: post #163
jackmaney wrote: post #136

Earlier quoted context omitted.

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.

Um, I think you're agreeing. "Instead, you [i.e., not the deserializer] should map task to an array of values."

Re: PostgreSQL 9.4 Released

#174

Post by otis_inf »

dodyg wrote: post #160
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…

LLBLGen Pro has an excellent LINQ provider as well.

Thanks, dodyg :)

Re: PostgreSQL 9.4 Released

#175

Post by nonuby »

Whats a good place to suggest a postgresql [json] improvement, my message was intercepted when posting to pg-performance. A major one at the moment is that offset does the select projection on discarded rows (common to use offset in paging), under normal circumstances this isn't a problem, however when does a json operation such as reading a field ->> this causes major performance degrading. Note of course only immutable functions can this optimization apply. There are several workarounds but if PostgreSQL wants to win back some nosql heads it should be straight forward.

In addition to update a json field isn't straight forward, these operations should be supported by first class inbuilt functions.

Its getting close but its not quite a nosql killer yet if they are targetting people who didn't originally come from rdbms background..

Re: PostgreSQL 9.4 Released

#176

Post by mslot »

digitalzombie wrote: post #22
k_sze wrote: post #7

Bye bye MongoDB.

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.

Depending on your exact requirements, you can use pg_shard [1] for real-time inserts/update/delete, or CitusDB [2] for scaling out selects, or combine them.

[1] https://github.com/citusdata/pg_shard [2] http://www.citusdata.com/

Disclaimer: I work for Citus Data.

Re: PostgreSQL 9.4 Released

#177

Post by otis_inf »

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…

> Microsoft writing a LINQ provider for PgSql is a great thing for running .NET code on non-Windows platforms.

I've heard nothing of this kind with respect to npgsql, which is the current .NET provider for PostgreSql. Microsoft has never spent a minute on EF support in Npgsql, so that they bother now is a first. The thing is that to support EF in npgsql (or any other ADO.NET provider), the ADO.NET provider has to contain a command interpreter which interprets the command trees coming from EF's linq provider, and which are then to be used to create SQL statements. This isn't simple at all, and as the command trees change with EF7, it will be a struggle for MS to get a lot of ADO.NET providers support EF7 at the start.

Microsoft's only great linq provider is the one in Linq to Sql: it is able to handle a tremendous amount of edge cases. The thing with linq providers is that a general linq provider gets you only that far: a tremendous amount of cases are 'special cases' which have to get their own path to get from the expression-tree to specific sql. e.g.: ctx.A.Select(a=>a.B.Cs);. This gives a set of sets of C instances. To do this, you have to know at the materialization side which C rows belong to which set (as you have to group them by B, which isn't in the projection). Linq to Sql has a specific piece of code for this, it produces a specifically grafted SQL query which contains an extra column so the materializer can know which C rows to group together. EF doesn't, it obtains a big joined soup.

Irony is that EF7's linq provider will be built on Relinq, which is also the base of NHibernate's linq provider, and they didn't re-use the Linq to sql linq provider, which is kind of odd, considering linq to sql's is pretty db agnostic.

Writing a linq provider isn't simple btw. It took me a full year full time to write the one for LLBLGen Pro.

Re: PostgreSQL 9.4 Released

#178

Post by icebraining »

NickNameNick wrote: post #153
pilif wrote: post #35

Earlier quoted context omitted.

When I say "code archeology", I mean the equivalent of "git blame" without assigning blame - just finding out why stuff is the way it is and not who's responsible because that would be totally pointless, especially years after the incident. I do like your spin however :-)

Praise is a built-in alias for SVN, not so for git unfortunately.

Ditto in Bazaar, which copied SVN. But there's an easy fix:

  git config --global alias.praise blame

Re: PostgreSQL 9.4 Released

#179

Post by illumen »

devonnulled wrote: post #61
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…

Hey there. I gave a talk at PGConfNYC '14 earlier this year about our solution to HA using open source solutions. The animations and stuff don't really work too well on Slideshare, but it should point you in the right direction: http://www.slideshare.net/TeamARIN/building-a-high-availabil... pgSQL doesn't have anything built in for fencing, failing-over, etc. by default, but by using stuff like Pacemaker, you can get…

Do you have any scripts to set up a cluster for this? Or know where to look?

Re: PostgreSQL 9.4 Released

#180

Post by atonse »

lewaldman wrote: post #103
bkeroack wrote: post #66

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.

We've been running mostly VMs all this time on our app (Windows, SQL Server, Linux w/ Rails), but have been using more and more ACTUAL AWS services (SQS, DynamoDB, Redshift).

I can maybe see where those latter amazon specific services are a lock-in. But I still don't see it that way, really. They aren't a lock-in from the perspective of the code if you put everything behind service interfaces with different implementations. The big guys like Azure and Google Compute all have similar services for DB as a service, blob storage, VMs, etc.

But the act of migrating to something like Azure is just generally a lot of work in ensuring 0 downtime and a smooth transition. That's hard no matter what technologies we use.

And we've talked about it. But just the act of moving is, in my opinion, a multi-week migration process with load tests etc.

And the cost savings would have to outweigh the amount of engineering costs of moving.

All this to say, the real lock-in is lack of dissatisfaction in our situation. "Amazon works well enough for us."

Post reply on HN