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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
