Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
От | Andres Freund |
---|---|
Тема | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Дата | |
Msg-id | 20160902162553.xgcnvnggxhnztaun@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) (Kevin Grittner <kgrittn@gmail.com>) |
Ответы |
Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
|
Список | 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
В списке pgsql-hackers по дате отправления: