tag:blogger.com,1999:blog-7609611625311126307.post3222246429563351521..comments2023-07-15T17:01:46.391-07:00Comments on Peter Geoghegan's blog: What I think of jsonbPeter Geogheganhttp://www.blogger.com/profile/02874568372191778321noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-7609611625311126307.post-66475372257389824452014-08-01T05:58:42.323-07:002014-08-01T05:58:42.323-07:00Perhaps you would know the answer to a jsonb quest...Perhaps you would know the answer to a jsonb question: TOAST does not seem to do any compression on this format, even for large json docs. Is that by design?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7609611625311126307.post-44858880495820844942014-07-26T10:29:08.077-07:002014-07-26T10:29:08.077-07:00I hope all of those TFS performance improvements f...I hope all of those TFS performance improvements from 2012 went into the PostgreSQL 9.4 codebase.<br /><br />If they are, they should get a lot more attention. They should at least be mentioned in the PostgreSQL 9.4 release notes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7609611625311126307.post-65372787588666787852014-04-22T15:55:48.417-07:002014-04-22T15:55:48.417-07:00hstore is going to continue to be useful as a simp...hstore is going to continue to be useful as a simple key/value store, but I don't think it's likely to expand in scope, given the discussion on list. jsonb is in a certain sense the successor of hstore, given the technical foundation that they share, but that's about the extent of it.<br /><br />Originally, we thought that hstore could be made to support multiple input formats, an hstore compatible one, and a JSON one, but during our discussion it transpired that that probably wasn't worth it. Personally, I'm happy to let hstore be hstore. I think that jsonb is definitely the area that we'll target for future improvements to general handling of semi-structured or unstructured data.Peter Geogheganhttps://www.blogger.com/profile/02874568372191778321noreply@blogger.comtag:blogger.com,1999:blog-7609611625311126307.post-64420805343909199142014-04-13T11:32:56.681-07:002014-04-13T11:32:56.681-07:00This is indeed going to be a cool feature. We made...This is indeed going to be a cool feature. We made tests with a different bson implementation and PostgreSQL and it was much faster than MongoDB, so I expect about the same speed-up. In many use cases, people will be much better off with PostgreSQL then.<br /><br />What I don't really understand is the roadmap regarding jsonb and hstore. Is jsonb going to be the ultimate type for document-style data? Will it supersede hstore or will they coexist? As I read in a presentation from Oleg, hstore in (probably) 9.4 has similar features to offer.Jenshttps://www.blogger.com/profile/02753541486208436380noreply@blogger.comtag:blogger.com,1999:blog-7609611625311126307.post-27622119480578763732014-03-26T10:18:02.045-07:002014-03-26T10:18:02.045-07:00Congrats to the Postgres team. jsonb is an exciti...Congrats to the Postgres team. jsonb is an exciting feature and I'm looking forward to it! Thanks for all your hard work!Ryan Duryeahttps://www.blogger.com/profile/12246958727786294229noreply@blogger.comtag:blogger.com,1999:blog-7609611625311126307.post-35819078156485083652014-03-24T23:17:04.560-07:002014-03-24T23:17:04.560-07:00 I very like your notice, that jsonb is a conseque... I very like your notice, that jsonb is a consequence of our (I and Teodor Sigaev) more than decade development - intarray, tsearch, hstore, ltree, full text search, pg_trgm, GiST, GIN, SP-GiST are all about semi-structured data. Oleg Bartunovhttps://www.blogger.com/profile/03096674393459633701noreply@blogger.com