Re: about google summer of code 2016
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: about google summer of code 2016 |
Дата | |
Msg-id | 56CB8A62.40100@8kdata.com обсуждение исходный текст |
Ответ на | Re: about google summer of code 2016 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: about google summer of code 2016
Re: about google summer of code 2016 |
Список | pgsql-hackers |
On 22/02/16 05:10, Tom Lane wrote: > Heikki Linnakangas <hlinnaka@iki.fi> writes: >> On 19/02/16 10:10, Ã�lvaro Hernández Tortosa wrote: >>> Oleg and I discussed recently that a really good addition to a GSoC >>> item would be to study whether it's convenient to have a binary >>> serialization format for jsonb over the wire. >> Seems a bit risky for a GSoC project. We don't know if a different >> serialization format will be a win, or whether we want to do it in the >> end, until the benchmarking is done. It's also not clear what we're >> trying to achieve with the serialization format: smaller on-the-wire >> size, faster serialization in the server, faster parsing in the client, >> or what? > Another variable is that your answers might depend on what format you > assume the client is trying to convert from/to. (It's presumably not > text JSON, but then what is it?) As I mentioned before, there are many well-known JSON serialization formats, like: - http://ubjson.org/ - http://cbor.io/ - http://msgpack.org/ - BSON (ok, let's skip that one hehehe) - http://wiki.fasterxml.com/SmileFormatSpec > > Having said that, I'm not sure that risk is a blocking factor here. > History says that a large fraction of our GSoC projects don't result > in a commit to core PG. As long as we're clear that "success" in this > project isn't measured by getting a feature committed, it doesn't seem > riskier than any other one. Maybe it's even less risky, because there's > less of the success condition that's not under the GSoC student's control. Agreed :) Álvaro -- Álvaro Hernández Tortosa ----------- 8Kdata
В списке pgsql-hackers по дате отправления: