On 1/24/17 10:43 PM, Jim Nasby wrote:
>
>> 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.
I've attached the results of that. Unfortunately the speed improvement
is only 27% at this point (with 9999999 tuples). Presumably that's
because it's constructing a brand new dictionary from scratch for each
tuple.
--
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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
