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