On 27Jan2013 21:57, Jason Friedman <jsf80...@gmail.com> wrote:
| > On 26Jan2013 09:48, Matt Jones <matt.walker.jo...@gmail.com> wrote:
| > | It sounds like your real problem is with your SQL query... Is that part
of
| > | this problem under your control? Can you break the query into smaller,
| > | quicker, pieces that you can run in a reasonable amount of time?
| >
| > Another option to investigate is whether you can ask the database itself
| > to limit the run time of a query. Of course, that will abort the query
| > but so does your proposed solution.
| >
| > Another approach might be to simply run each query regularly (with a
| > pause between so the database is not spending its whole life running
| > your query). Snapshot each latest result. Compute your report from the
| > latest pair of snapshots at any given time on an independent schedule.
| > It may not be valid for what you need, but if it is then this decouples
| > you from the query time completely.
|
| Along these lines, if you are running on Linux then the bash shell
| comes with a "timeout" command, which you can prepend to snapshot
| requests.
I was thinking that if he does something equivalent to:
while :; do run-sql-query1-with-snapshot-of-result; sleep 900; done &
while :; do run-sql-query2-with-snapshot-of-result; sleep 900; done &
while :
do
report on latest pair of snapshots
sleep 7200
done
Then he doesn't need any timeouts.
Cheers,
--
Cameron Simpson <c...@zip.com.au>
--
http://mail.python.org/mailman/listinfo/python-list
