Thanks for your assistance guys, and special thanks to Greg for his
blog page.
This is exactly my problem which is resolved using dynamic SQL. I can
now see how the function was behaving badly, and have been able to fix
the query.
Once again, thanks guys - and Happy New Year from a snow-covered pa
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> And when I execute the function with the same parameters it takes well
> over 5 minutes to execute.
>
> It seems as though inside a function, the optimizer wants to tablescan
> my 8M row table. Is there a way that I can see the query plans tha
On 1/01/2010 12:05 AM, Chris McDonald wrote:
FOR matchRecord IN
same query as above
LOOP
RETURN NEXT matchRecord.evaluationid;
END LOOP;
And when I execute the function with the same parameters it takes well
over 5 minutes to execute.
It's as if you PREPAREd the query once, and each
Hi everyone.
I am using postgresql 8.3.7 on Fedora Core 10. I have 1 table called
evaluation which contains about 1 million records, and another called
evaluationentry which contains about 9 million records.
evaluationentry.veto and evaluation.relevancedt both have indexes on
them. I have run ANAL
