Thanks for your help Андрей your English is easily understandable and
much better than my ... (Russian?). I managed to get the results of an
analyze and this showed that an index was not being used correctly. It
seems that I was passing in a varchar and not casting it to an int and
this stopped
Thanks Euler,
I made the change to STABLE but it didn't seem to make any difference.
On closer inspection it seems to have been a casting problem, I was
passing a varchar into the function and then testing this for equality
with an integer. The planner seems to have been unable to use this t
Matthew Lunnon wrote:
Ahh, sorry, I have been too aggressive with my cutting, I am running
8.2.6 and the function is below.
$BODY$
LANGUAGE 'sql' VOLATILE;
^^
I suspect that it's because you're using VOLATILE (so no good
optimizations is done); did you try STABL
Ahh, sorry, I have been too aggressive with my cutting, I am running
8.2.6 and the function is below.
Thanks.
Matthew
CREATE OR REPLACE FUNCTION sp_get_price_panel_id(int4, "varchar",
"varchar", "varchar", bpchar)
RETURNS SETOF t_market_price_panel AS
$BODY$
SELECT *
FROM market mrkt
J
Matthew Lunnon wrote:
I have a query which runs pretty quick ( 0.82ms) but when I put it
inside a stored procedure it takes 10 times as long (11.229ms). Is
this what you would expect and is there any way that I can get around
this time delay?
It depends. You'll need to show us the function.
Hi ms
I have a query which runs pretty quick ( 0.82ms) but when I put it
inside a stored procedure it takes 10 times as long (11.229ms). Is
this what you would expect and is there any way that I can get around
this time delay?
postgres.conf changes.
shared_buffers = 500MB
work_mem = 10MB
