On 1/23/17 10:36 PM, Craig Ringer wrote:
> which is currently returned as
>
> [ {"a":1, "b":10}, {"a":2, "b":20} ]
>
> instead as
>
> { "a": [1, 2], "b": [10, 20] }
Correct.
> If so I see that as a lot more of a niche thing. I can see why it'd be
> useful and would help performance, but it seems much more disruptive.
> It requires users to discover it exists, actively adopt a different
> style of ingesting data, etc. For a 10%-ish gain in a PL.
In data science, what we're doing now is actually the niche. All real
analytics happens with something like a Pandas DataFrame, which is
organized as a dict of lists.
This isn't just idle nomenclature either: organizing results in what
amounts to a column store provides a significant speed improvement for
most analytics, because you're working on an array of contiguous memory
(at least, when you're using more advanced types like DataFrames and
Series).
> I strongly suggest making this design effort a separate thread, and
> focusing on the SPI improvements that give "free" no-user-action
> performance boosts here.
Fair enough. I posted the SPI portion of that yesterday. That should be
useful for pl/R and possibly pl/perl. pl/tcl could make use of it, but
it would end up executing arbitrary tcl code in the middle of portal
execution, which doesn't strike me as a great idea. Unfortunately, I
don't think plpgsql could make much use of this for similar reasons.
I'll post a plpython patch that doesn't add the output format control.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)