Re: Wanted: jsonb on-disk representation documentation

On Wed, May 7, 2014 at 4:40 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> * Imo we need space in jsonb ondisk values to indicate a format
> version. We won't fully get this right.

That would be nice.

> * The jentry representation should be changed so it's possible to get the type
> of a entry without checking individual types. That'll make code like
> findJsonbValueFromSuperHeader() (well, whatever you've renamed it to)
> much easier to read. Preferrably so it an have the same values (after
> shifting/masking) ask the JBE variants. And it needs space for futher
> types (or representations thereof).

I don't know what you mean. Every place that macros like
JBE_ISNUMERIC() are used subsequently involves access to (say) numeric
union fields. At best, you could have those functions check that the
types match, and then handle each case in a switch that only looked at
(say) the "candidate", but that doesn't really save much at all. It
wouldn't take much to have the macros give enum constant values back
as you suggest, though.

> * I wonder if the hash/object pair representation is wise and if it
> shouldn't be keys combined with offsets first, and then the
> values. That will make access much faster. And that's what jsonb
> essentially is about.

I like that the physical layout reflects the layout of the original
JSON document. Besides, I don't think this is obviously the case. Are
you sure that it won't be more useful to make children as close to
their parents as possible? Particularly given idiomatic usage. Jsonb,
in point of fact, *is* fast.

> * I think both arrays and hashes should grow individual structs. With
> space for additional flags.

Why?

--
Peter Geoghegan