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
