I've been dealing with a problem for the past two days
where a certain sql statement works 2 out of 5 times, and
the other 3 times, it causes the machine (quad Xeon 2.8GHz
+ 792543232 bytes mem, linux kernel 2.4.26-custom, pg ver 7.3.4)
to slow down, and finally grind to a halt. It looks like postgres
gets itself into an insane loop, because no matter how much
shared memory I give it, it uses it all, and then
the kernel starts swapping.
I'm pretty sure it's not the kernel, because I've tried four different
2.4.2* stable kernels, and the same happens.
I've attached the query, and the functions used inside the query,
as well as the table structure and an explain. (I haven't been
able to get explain analyze)
It seems that when I replace the functions used in the query,
with the actual values returned by them (one date in each case),
the query runs in 10 seconds.
I did vacuum analyze, and reindex seemed to work at one
stage, but now it doesn't anymore.
Is there some limitation in using functions that I do not know
about, or is it a bug?
(It seems to be hanging on the max_fpp('''')
function call from inside the fpp_max_ms() function.)
Description: application/octet-stream (546 bytes)
Description: text/plain (2.4 KB)
Description: application/octet-stream (1.3 KB)
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2004-06-07 13:51:56|
|Subject: Re: Relation of cpu_*_costs? |
|Previous:||From: Kris Jurka||Date: 2004-06-07 09:26:38|
|Subject: Re: Using a COPY...FROM through JDBC?|