On 8/16/10 8:40 AM, Christopher Browne wrote:
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas<robertmh...@gmail.com> wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Andrew Dunstan<and...@dunslane.net> writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might
want to consider storing the data in this supposedly more efficient
format, and maybe also some conversion routines.
Hmm, that's an interesting plan ...
It is interesting, but I'm not sure that it will actually work out
well in practice. If what we want to do is compress JSON, TOAST will
do that for us without any additional code, and probably a lot more
efficiently. Of course, until someone tests it, we're just
speculating wildly.
Yep, that was exactly what struck me. TOAST is quite likely to be a
good answer for this.
The reason to want some other binary format would be if there were
other benefits to be had.
An "XML encoding" format could be interesting if it allowed having
GIST-ish indexes to search for tags particularly efficiently. I say
"XML encoding" because I've not got any reason to think that a
JSON/BSON-only format would necessarily be preferable.
But "interesting" isn't the same thing as "the right answer." For
now, TOAST seems perfectly reasonable.
If there's some "wire format for XML" that would allow more efficient
data transfer, that would be an improvement. BSON sounds like it's
something like that, but only if it's better than "flavour of the
week."
XML encoding has certainly been investigated within the W3C public docs:
http://www.w3.org/2003/08/binary-interchange-workshop/Report.html
(discussion)
http://www.w3.org/TR/xbc-characterization/ (summary)
Leading to the current draft of EXI:
http://www.w3.org/XML/EXI/
The spec is a rather large undertaking. It makes sense to add to the XML
ToDo wiki page.
EXI will certainly be better than TOAST for larger XML docs.
...
BSON does not compress text content -- TOAST would still have its
advantages.
It mainly shortens the representation of JSON data structures.
Again, I think the primary benefit of BSON would be data traversal.
The benefit is the same for a client receiving BSON, as the server.
Data lengths are specified, allowing quick optimizations for things like
key_exists
and equivalencies. Client's supporting BSON could benefit from a quick
pass-through.
And I'd imagine a very slight benefit toward indexing, were GIN / hstore
processes used.
Still, as has been noted on this thread.. We don't have numbers to work
with.
With json as a core data type; and "bson" as a possible function working
with the json
type, there's not much of a risk going in either direction (text +
TOAST, bson + TOAST).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
