On 01/26, Matt Jones wrote: The SQL part is not under control and getting it there requires more development time than the management is willing to allocate. So this would be a first step before refactoring that part. I'm aware that the database might not notice that I don't want to receive the result of the query, but I'm willing to assume that risk for now.
Thank you. > 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? > > If not, nesting threads might be your best programmatic solution. Heed > Jason's warning though that the SQL Server my still be working even if you > cancel an operation from the outside (which could compound your problem). > > *Matt Jones* > > > On Sat, Jan 26, 2013 at 9:43 AM, Jason Friedman <jsf80...@gmail.com> wrote: > > > > Sometimes it happens that a query on one of the database servers > > > takes longer than expected and impedes the generation of this report > > > (that's right, the queries are ran sequential). What I am trying to > > > achieve is to parallelize the queries on each database server and to be > > > able to cancel one of them if it takes longer than X minutes. > > > > Only answering a small portion of your question .... > > Assuming you are able to figure out how to "cancel" a thread or > > process on your side, it is possible the database itself will not > > respect that. In other words, if you execute "SELECT ..." singly, > > outside of Python, and type CNTL-C, does your database quickly > > recognize you are no longer interested in the result set and stop its > > work? > > -- > > http://mail.python.org/mailman/listinfo/python-list > > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
