Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
От | Robert Haas |
---|---|
Тема | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Дата | |
Msg-id | CA+TgmoYoWja8V8iKb7GhT7LivydkGmuSiO6QOvaEjeU+iMKWpQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Implement targetlist SRFs using ROWS FROM() (was
Changed SRF in targetlist handling)
|
Список | pgsql-hackers |
On Sun, Aug 28, 2016 at 3:18 AM, Andres Freund <andres@anarazel.de> wrote: > 0003-Avoid-materializing-SRFs-in-the-FROM-list.patch > To avoid performance regressions from moving SRFM_ValuePerCall SRFs to > ROWS FROM, nodeFunctionscan.c needs to support not materializing > output. > > In my present patch I've *ripped out* the support for materialization > in nodeFunctionscan.c entirely. That means that rescans referencing > volatile functions can change their behaviour (if a function is > rescanned, without having it's parameters changed), and that native > backward scan support is gone. I don't think that's actually an issue. Can you expand on why you think those things aren't an issue? Because it seems like they might be. > 0006-Remove-unused-code-related-to-targetlist-SRFs.patch > Now that there's no targetlist SRFs at execution time anymore, rip out > executor and planner code related to that. There's possibly more, but > that's what I could find in a couple passes of searching around. > > This actually speeds up tpch-h queries by roughly 4% for me. Nice. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: