Re: Storage formats for JSON WAS: additional json functionality

Greg,

> Not being super familiar with either BSON our JSONB what advantages are we
> gaining from the difference?

We have the JSONB/Hstore2 format *now*, and it can go into 9.4. This
makes it inherently superior to any theoretical format. So any further
discussion (below) is strictly academic, for the archives.

> It might be interesting if we supported the same binary representation so
> we could have a binary send/recv routines that don't need to do any
> serialization/deserialization. Especially since a standard format would
> potentially be skipping the serialization/deserialization on both the
> server and client.

Leaving aside that we don't want to implement 10gen's spec (because of
major omissions like decimal numbers), the fundamental issue with
binary-update-in-place is that nobody (certainly not 10gen) has devised
a way to do it without having ginormous amounts of bloat in value
storage. The way BSON allows for binary-update-in-place, as I
understand it, is to pad all values with lots of zero bytes and to
prohibit compression, either of which are much larger losses for
performance than serialization is.

In other words, binary-update-in-place seems like a clear win for
heirarchical data storage, but practically it's not.

Of course, an investigation into this by someone with much more
knowledge of low-level storage than me (most of this list) is welcome.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com