From: | "Benjamin Krajmalnik" <kraj(at)illumen(dot)com> |
---|---|
To: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Inserting a timed delay in a pl/pgsql procedure |
Date: | 2006-08-18 19:26:24 |
Message-ID: | BF337097BDD9D849A2F4B818DDB27987252603@stash.stackdump.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
I have a problem right now where the execution time of a scheduled
stored procedure is creating an issue with our background data logging
system.
Initially I thought it may be caused due to table locks or the like, but
after much testing I have ruled that out, since data is being inserted
while the scheduled SP runs.
The problem cause is one over which unfortunately I have no control.
However, I wanted to run a test and see if I cuold minimize the problem
by inserting a delay in the stored procedure so that after each loop of
the data aggregation, it "sleeps" for a second or so to let the
backround logger despool its queue.
I tried the following:
FOR myrecord in select * from tblkstests where stats = true and
accountno=423 LOOP
returndate := fn_calcteststats(myrecord.kstestssysid);
nextexecdate := returndate + interval '0.25 second';
LOOP
EXIT when current_timestamp > nextexecdate;
END LOOP;
END LOOP;
However, it appears that current_timestamp is not being recalculated.
Any ideas? While normally we want the stored procedures to run as
quickly as possible, this is a case where I need to insert a delay.
I guess an option would be to place a counter and loop through it, but
it does not allow me the control I relly need.
I am not sure this will resolve the problem, but it's a start.
From | Date | Subject | |
---|---|---|---|
Next Message | John DeSoi | 2006-08-18 19:50:02 | Re: Inserting a timed delay in a pl/pgsql procedure |
Previous Message | Alvaro Herrera | 2006-08-18 15:32:13 | Re: vacuumdb exclude tables option? |