Re: WIP Patch: Add a function that returns binary JSONB as a bytea

On 2018-11-02 23:24:35 +0100, David Fetter wrote:
> On Wed, Oct 31, 2018 at 11:18:46AM -0400, Stephen Frost wrote:
> > Greetings,
> >
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > > > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > > >> I dunno, I do not think it's a great idea to expose jsonb's internal
> > > >> format to the world. We intentionally did not do that when the type
> > > >> was first defined --- that's why its binary I/O format isn't already
> > > >> like this --- and I don't see that the tradeoffs have changed since then.
> > >
> > > > I disagree- it's awfully expensive to go back and forth between string
> > > > and a proper representation.
> > >
> > > Has anyone put any effort into making jsonb_out() faster? I think that
> > > that would be way more productive. Nobody is going to want to write
> > > code to convert jsonb's internal form into whatever their application
> > > uses; particularly not dealing with numeric fields.
> >
> > I'm all for making jsonb_out() faster, but even a faster jsonb_out()
> > isn't going to be faster than shoveling the jsonb across.
>
> Would it be completely batty to try store JSONB on disk in wire format
> and optimize accesses, indexing, etc. around that?

It doesn't seem to make any sense whatsoever. For one, the current wire
format is text. If that's your argument, uh, yes, we have jsonb over
json for a reason. If you're talking about a hypothetical future wire
format, that seems unlikely as well - for one there's obviously on-disk
compat issues, for another, the on-disk format is already kind of
optimized to store what it stores. And on-wire and on-disk concerns are
different.

Greetings,

Andres Freund