Hi, discussing executor performance with a number of people at pgcon, several hackers - me included - complained about the additional complexity, both code and runtime, required to handle SRFs in the target list.
One idea I circulated was to fix that by interjecting a special executor node to process SRF containing targetlists (reusing Result possibly?). That'd allow to remove the isDone argument from ExecEval*/ExecProject* and get rid of ps_TupFromTlist which is fairly ugly. Robert suggested - IIRC mentioning previous on-list discussion - to instead rewrite targetlist SRFs into lateral joins. My gut feeling is that that'd be a larger undertaking, with significant semantics changes. If we accept bigger semantical changes, I'm inclined to instead just get rid of targetlist SRFs in total; they're really weird and not needed anymore. One issue with removing targetlist SRFs is that they're currently considerably faster than SRFs in FROM: tpch[14693][1]=# COPY (SELECT * FROM generate_series(1, 10000000)) TO '/dev/null'; COPY 10000000 Time: 2217.167 ms tpch[14693][1]=# COPY (SELECT generate_series(1, 10000000)) TO '/dev/null'; COPY 10000000 Time: 1355.929 ms tpch[14693][1]=# I'm no tto concerned about that, and we could probably fixing by removing forced materialization from the relevant code path. Comments? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
