I have a varchar field which is most commonly queried like "someField like '%abcd'". Realizing that it wouldn't be able to use an index for this type of query I created a reverse() function and an index using the function reverse(someField) so that the query would be performed as "reverse(someField) like reverse('%abcd')". When I looked at the query plan it seemed like it was using the new reverse index properly but also seemed to run slower. Would this explain these bazaar results? I have since gone back to the method without using the reverse function. Thanks
Stuart Bishop <stuart@stuartbishop.net> 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
---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
