Re: combination of function to simple query makes query slow

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "jan aerts (RI)" <jan(dot)aerts(at)bbsrc(dot)ac(dot)uk>
Cc: "Jaime Casanova" <systemguards(at)gmail(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: combination of function to simple query makes query slow
Date: 2005-10-04 14:50:07
Message-ID: 8195.1128437407@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"jan aerts (RI)" <jan(dot)aerts(at)bbsrc(dot)ac(dot)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

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message solarsail 2005-10-04 16:30:55 using pg_tables and tablename in queries
Previous Message jan aerts (RI) 2005-10-04 08:27:56 Re: combination of function to simple query makes query slow