To: "jan aerts (RI)" <jan.aerts@bbsrc.ac.uk>
Cc: "Jaime Casanova" <systemguards@gmail.com>,
	pgsql-sql@postgresql.org
Subject: Re: combination of function to simple query makes query slow 
In-reply-to: 
 <84DA9D8AC9B05F4B889E7C70238CB45101FD6557@rie2ksrv1.ri.bbsrc.ac.uk>
References: 
 <84DA9D8AC9B05F4B889E7C70238CB45101FD6557@rie2ksrv1.ri.bbsrc.ac.uk>
Comments: In-reply-to "jan aerts (RI)" <jan.aerts@bbsrc.ac.uk>
	message dated "Tue, 04 Oct 2005 09:27:56 +0100"
Date: Tue, 04 Oct 2005 10:50:07 -0400
Message-ID: <8195.1128437407@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"jan aerts (RI)" <jan.aerts@bbsrc.ac.uk> writes:
> My Postgres version is 7.3.4 (on a central server, so I can't upgrade if
> that would be one of the suggestions...)

7.3.4 has multiple known data-loss bugs and security issues.  If you're
dealing with someone who won't upgrade it, find someone else to deal
with.  At the very least they need to move to 7.3.10 (or as of today,
7.3.11).  See
http://developer.postgresql.org/docs/postgres/release-7-3-11.html
and following pages for reasons why.

> I thought that making a function stable or immutable would make it
> available for an index search.

Your problem isn't the function, it's the IN (SELECT ...) construct.
7.3 is not bright enough to optimize that.  (Given that it's a
correlated sub-SELECT, I'm afraid later releases aren't either :-(.)
You need to find a way of expressing the query without that.

My guess is that trying to use a function for this is counterproductive
in itself; the table access that's going on inside the function needs
to be exposed for optimization in order to get reasonable overall
performance.

			regards, tom lane