On Sun, May 1, 2016 at 6:46 AM, Tom Smith <tomsmith198...@gmail.com> wrote:
> Hello: > > I'd like to bring this JSONB performance issue again. > Below is a link of MySQL way of storing/retrieving Json key/value > > https://dev.mysql.com/doc/refman/5.7/en/json.html > > Instead of providing column indexing(like GIN for JSONB in Postgresql). > it provides only internal data structure level indexing within each > individual json object > for fast retrieval. compression is not used. > > Perhaps without implementing complicated column level GIN indexing, > implementing > a new variant JSON type that only handle individual json object indexing > would be > feasible? Combined with current JSONB implementation, both common use > cases > (one is global doc indexing, the other is fast retrieval of individual > values) > would work out and make postgresql unbeatable. > It's called expression index ? > > > > > > > > > > On Tue, Jan 19, 2016 at 8:51 PM, Bruce Momjian <br...@momjian.us> wrote: > >> On Mon, Jan 11, 2016 at 09:01:03PM -0500, Tom Smith wrote: >> > Hi, >> > >> > Congrats on the official release of 9.5 >> > >> > And I'd like bring up the issue again about if 9.6 would address the >> jsonb >> > performance issue >> > with large number of top level keys. >> > It is true that it does not have to use JSON format. it is about >> serialization >> > and fast retrieval >> > of dynamic tree structure objects. (at top level, it might be called >> dynamic >> > columns) >> > So if postgresql can have its own way, that would work out too as long >> as it >> > can have intuitive query >> > (like what are implemented for json and jsonb) and fast retrieval of a >> tree >> > like object, >> > it can be called no-sql data type. After all, most motivations of using >> no-sql >> > dbs like MongoDB >> > is about working with dynamic tree object. >> > >> > If postgresql can have high performance on this, then many no-sql dbs >> would >> > become history. >> >> I can give you some backstory on this. TOAST was designed in 2001 as a >> way to store, in a data-type-agnostic way, long strings compressed and >> any other long data type, e.g. long arrays. >> >> In all previous cases, _part_ of the value wasn't useful. JSONB is a >> unique case because it is one of the few types that can be processed >> without reading the entire value, e.g. it has an index. >> >> We are going to be hesitant to do something data-type-specific for >> JSONB. It would be good if we could develop a data-type-agnostic >> approach to has TOAST can be improved. I know of no such work for 9.6, >> and it is unlikely it will be done in time for 9.6. >> >> -- >> Bruce Momjian <br...@momjian.us> http://momjian.us >> EnterpriseDB http://enterprisedb.com >> >> + As you are, so once was I. As I am, so you will be. + >> + Roman grave inscription + >> > >
