Re: Slow functional indexes?

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

On 11/5/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Stuart Bishop <stuart(at)stuartbishop(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Gene Hart
cell: 443-604-2679