Just a quick historical note: Back in 2016 [1], Andres had raised similar concerns about executor overhead from deforming unneeded columns, but at the time (pre-ExprEvalStep), expression evaluation wasn’t yet structured enough for that overhead to show up clearly in profiles. I see that Tom replied then too that the CPU cost of deforming extra columns would likely be lost in the noise.
That may have been fair back then, but I don’t think it holds anymore. With today’s step-driven ExecInterpExpr(), perf profiles of even simple OLAP queries like: SELECT sum(col1) FROM tbl WHERE col30 = 123; show substantial time spent in slot_getsomeattrs_int() and related deforming code. This is with the table fully cached, so we’re talking pure CPU overhead. Skipping deformation of columns not referenced in quals or targetlists can materially reduce runtime in such cases. Also, I forgot to mention in my earlier email that I’m proposing this work partly based on recent off-list discussions with Andres. I think the cost-benefit tradeoff is different now and worth reevaluating, even if only some real-world schemas end up benefiting. So, I’ll go off and prototype a version where the needed attributes are collected during expression tree initialization, in a generic enough way that any expression whose evaluation might involve a deforming step will benefit. -- Thanks, Amit Langote [1] https://www.postgresql.org/message-id/flat/20160722015605.hpthk7axm6sx2mur%40alap3.anarazel.de
