From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: UNNEST with multiple args, and TABLE with multiple funcs |
Date: | 2013-08-14 00:32:41 |
Message-ID: | 520AD029.1060001@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/14/2013 08:22 AM, Josh Berkus wrote:
> On 08/13/2013 06:54 AM, Andrew Gierth wrote:
>> Summary:
>>
>> This patch implements a method for expanding multiple SRFs in parallel
>> that does not have the surprising LCM behaviour of SRFs-in-select-list.
>> (Functions returning fewer rows are padded with nulls instead.)
>
> BTW, if anyone is unsure of the use-case for this, I have some uses for it:
>
> 1. denormalized data stored in same-length arrays (usually for
> compression reasons)
>
> 2. use with PL/Python-Numpy and PL/R functions which return multiple
> arrays or 2D arrays.
>
> In other words, I have *lots* of uses for this functionality, and I
> think the analytics crowd will like it. Which means that I need to get
> on testing it, of course ...
Similarly, I see uses for this come up a lot, and usually have to work
around it with ugly invocations of multiple SRFs in the SELECT list in a
subquery.
I was thinking of implementing multi-argument unnest directly with `any`
parameters if I could get it to work, but hadn't started on it yet.
This looks like a really clever approach and it handles multiple
spec-compliance items. I'll grab the patch and try it out.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-08-14 01:09:06 | dynamic shared memory |
Previous Message | Josh Berkus | 2013-08-14 00:22:06 | Re: UNNEST with multiple args, and TABLE with multiple funcs |