Andres Freund <and...@anarazel.de> writes: > 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.
I looked over this patch a bit. > 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. I think you are wrong on this not being an issue: it is critical that rescan deliver the same results as before, else for example having a function RTE on the inside of a nestloop will give nonsensical/broken results. I think what we'll have to do is allow the optimization of skipping the tuplestore only when the function is declared nonvolatile. (If it is, and it nonetheless gives different results on rescan, it's not our fault if joins give haywire answers.) I'm okay with not supporting backward scan, but wrong answers during rescan is a different animal entirely. Moreover, I think we'd all agreed that this effort needs to avoid any not-absolutely-necessary semantics changes. This one is not only not necessary, but it would result in subtle hard-to-detect breakage. It's conceivable that we could allow the executor to be broken this way and have the planner fix it by inserting a Material node when joining. But I think it would be messy and would probably not perform as well as an internal tuplestore --- for one thing, because the planner can't know whether the function would return a tuplestore, making the external materialization redundant. Another idea is that we could extend the set of ExecInitNode flags (EXEC_FLAG_REWIND etc) to tell child nodes whether they need to implement rescan correctly in this sense; if they are not RHS children of nestloops, and maybe one or two other cases, they don't. That would give another route by which nodeFunctionscan could decide that it can skip materialization in common cases. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers