To: Stuart Bishop <stuart@stuartbishop.net>
cc: Stuart Bishop <stuart.bishop@canonical.com>,
	pgsql-performance@postgresql.org
Subject: Re: Slow functional indexes? 
In-reply-to: <454E4AC7.9020201@stuartbishop.net> 
References: <45387666.204@canonical.com> <454E4AC7.9020201@stuartbishop.net>
Comments: In-reply-to Stuart Bishop <stuart@stuartbishop.net>
	message dated "Sun, 05 Nov 2006 12:34:15 -0800"
Date: Sun, 05 Nov 2006 20:23:44 -0500
Message-ID: <26921.1162776224@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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