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

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, kevinvan(at)shift(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Date: 2018-11-02 17:37:35
Message-ID: CAHyXU0xGMgq0V3dsqgVF8t1Cf-Vr2=9mNqeRmqNFgd2MLb145A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 2, 2018 at 11:15 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Greetings,
>
> * Merlin Moncure (mmoncure(at)gmail(dot)com) wrote:
> > On Fri, Nov 2, 2018 at 10:53 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Andres' point about alignment is a pretty good one as well, if it applies
> > > here --- I don't recall just what internal alignment requirements jsonb
> > > has. We have not historically expected clients to have to deal with that.
> >
> > I see your (and Andres') point; the binary wire format ought to lay on
> > top of the basic contracts established by other types. It can be
> > binary; just not a straight memcpy out of the server. The array and
> > composite type serializers should give some inspiration there on
> > serialization.
>
> Right- I agree w/ Tom and Andres on this part also.
>
> > I'll still stand other point I made though; I'd
> > really want to see some benchmarks demonstrating benefit over
> > competing approaches that work over the current formats. That should
> > frame the argument as to whether this is a good idea.
>
> What are the 'competing approaches' you're alluding to here? Sending
> text-format json across as we do today?

Yep -- exactly. For example, write a C client program that recursed
the structure and dumped it to stdout or assigned to dummy variables
(being mindful of compiler optimizations). I'd be contrasting this to
a C parsed json that did essentially the same thing, and rigging a
high scale test on the back of that. The assumption here is that the
ultimate consumer is not, say, a browser, but some client app that can
actually exploit the performance advantages (else, why bother?).

In my experience with arrays and composites, you can see significant
performance reduction and throughput increase in certain classes of
queries. However, some of the types that were the worst offenders
(like timestamps) have been subsequently optimized and/or are
irrelevant to json since they'd be passed as test anyways.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Ramsey 2018-11-02 18:02:10 Re: Compressed TOAST Slicing
Previous Message David Fetter 2018-11-02 17:29:12 Re: COPY FROM WHEN condition