I've got a new stripped down version of the binary json plugin on github:
https://github.com/tlaurenzo/pgjson
With all due warning of contrived benchmarks, I wrote some tests to see
where things stand. The test script is here:
https://github.com/tlaurenzo/pgjson/blob/master/testdocs/runbench
Robert,
I think I agree. At a minimum, I would like to see the "chosen" of the
competing priorities live on as an outside module for use by previous
versions. Even having proposed one, and soon to be two of the competing
implementations, it makes me nervous to commit to one at this juncture.
I'm
>
> Yeah, my concern is not whether the overhead will be zero; it's
> whether it will be small, yet allow large gains on other operations.
> Like, how much slower will it be to pull out a moderately complex 1MB
> JSON blob (not just a big string) out of a single-row, single-column
> table? If it's
>
> It doesn't do particularly well on my previous example of [1,2,3]. It
> comes out slightly shorter on ["a","b","c"] and better if the strings
> need any escaping. I don't think the float4 and float8 formats are
> very useful; how could you be sure that the output was going to look
> the same
>
>
> I'm still going to write up a proposed grammar that takes these items into
> account - just ran out of time tonight.
>
>
The binary format I was thinking of is here:
http://github.com/tlaurenzo/pgjson/blob/master/pgjson/shared/include/json/jsonbinary.h
This was just a quick brain dump and I
ki.takah...@gmail.com> wrote:
> On Wed, Oct 20, 2010 at 6:39 AM, Terry Laurenzo wrote:
> > The answer may be to have both a jsontext and jsonbinary type as each
> will
> > be optimized for a different case.
>
> I want to choose one format for JSON rather than having two t
On Tue, Oct 19, 2010 at 4:51 PM, Tom Lane wrote:
> Terry Laurenzo writes:
> > After spending a week in the morass of this, I have to say that I am less
> > certain than I was on any front regarding the text/binary distinction.
> I'll
> > take some time and b
On Tue, Oct 19, 2010 at 2:46 PM, Robert Haas wrote:
> On Tue, Oct 19, 2010 at 3:40 PM, Joseph Adams
> wrote:
> > On Tue, Oct 19, 2010 at 3:17 PM, Robert Haas
> wrote:
> >> I think we should take a few steps back and ask why we think that
> >> binary encoding is the way to go. We store XML as t
enumerate the attributes of what would make a good binary
encoding?
Terry
On Tue, Oct 19, 2010 at 8:57 AM, Andrew Dunstan wrote:
>
>
> On 10/19/2010 10:44 AM, Robert Haas wrote:
>
>> On Sat, Oct 16, 2010 at 12:59 PM, Terry Laurenzo wrote:
>>
>>>- It
> > I like as simple design as we can accept. ISTM format, I/O interface,
> > simple get/set, mapping tuple from/to object, and indexing are minimum
> > requirement.
>
> +1 to small start, but simple get/set are already debatable...
> For example, text/json conversion:
> A. SELECT ''::json;
> B.
Hi all -
I independently started some work on a similar capability as was contributed
back in August by Joey Adams for a json datatype. Before starting, I did a
quick search but for some reason didn't turn this existing thread up.
What I've been working on is out on github for now:
http://github.
11 matches
Mail list logo
