From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Date: | 2016-09-02 16:25:53 |
Message-ID: | 20160902162553.xgcnvnggxhnztaun@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-09-02 10:58:59 -0500, Kevin Grittner wrote:
> If it has no significant performance impact to maintain the
> historical order, then I have no problem with doing so.
It's not really a runtime issue, it's just a question of how to nicely
constraint the join order. There's no additional sorting or such.
> No. I'm arguing that we track the order coming out of different
> nodes during planning, and sometimes take advantage of it to avoid
> a sort which would otherwise be required.
I don't think that's realistically possible with SRFs, given they're
often in some language which we have no insight on from the planner
point of view. We could possibly hack something up for SQL SRFs (that'd
be nice, but I'm doubtful it's worth it), but for everything else it
seems unrealistic. What we could do is to add efficient
ROWS FROM (..) WITH ORDINALITY ORDER bY ordinality;
support.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-09-02 16:30:16 | Re: Tracking timezone abbreviation removals in the IANA tz database |
Previous Message | Kevin Grittner | 2016-09-02 16:08:02 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |