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
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 |