Stuart Bishop <stuart@xxxxxxxxxxxxxxxx> writes: > Here is a minimal test case that demonstrates the issue. Can anyone else > reproduce these results? Of the four EXPLAIN ANALYZE SELECT statements at > the end, the one that orders by a user created IMMUTABLE stored procedure is > consistently slower than the other three variants. Wow, interesting. I'm surprised we never realized this before, but here's the deal: the generated plan computes the ORDER BY expressions even if we end up not needing them because the ordering is created by an indexscan rather than an explicit sort step. (Such a sort step would of course need the values as input.) So the differential you're seeing represents the time for all those useless evaluations of the function. The difference in the estimated cost comes from that too --- the code doing the estimation can see perfectly well that there's an extra function call in the plan ... Not sure whether there's a simple way to fix this; it might take some nontrivial rejiggering in the planner. Or maybe not, but I don't have any cute ideas about it at the moment. I wonder whether there are any other cases where we are doing useless computations of resjunk columns? regards, tom lane
