Re: [HACKERS] Faster methods for getting SPI results (460%improvement)

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)