> > These connections perform only a few heavy weight SQL statements > (taking max 3-4 of real execution time). > > Most of the time is spent in the Firebird engine waiting for the next > fetch, > due to network latencies. > > In the engine ?
Yes, the engine would be **waiting** for the next fetch request from the client. > Probably you want to say in the application\client ? Also it is > very interesting how do you evaluate that numbers. Consider: - Timeout set to 10 minutes - a SELECT, which when tested using local IBExpert, that takes 1 minutes to execute and return a result set of 10,000 rows - the real client application which takes 0.2 seconds per row to perform some required operation. Based on your logic, the SELECT would be killed after 10 minutes, with only 3,000 rows having been processed by the client application. Following my logic, any time waiting for a "fetch" would not count, and thus all 10,000 rows would be processed -- but the transaction/connection would be 'active' for 33 minutes. > The main question is - do you need such benefit at all, and, if so, how > much > efforts you are willing to spend on it ? Yes, 'cus for me the true cost of a statement is not elapsed time but "working time". Sitting waiting doesn't cost anything. > If you insist on changes in implementation, please, specify exactly what > you > need and where it is implemented in a such way. Add logic to stop and start the timer in locations where the server is waiting for client requests/"fetch" operations. Where else is it implemented? I really don't know anywhere, however: 1- I don't know of any other engines which allow for results to be fetched in "pages". It is the fact that the results can be fetch in "pages" with Firebird that, IMO, raises the need for the additional level of 'accounting'. 2- my review of the MS SQL and Oracle documentation, all I found was about how the client could be configured to stop execution, not to have the server stop an operation itself. The only server side timeout references, I found, were for operations where the engine was acting as a client to perform operations against another database/remote connections. Sean P.S. I am not even going to suggest that the time spent on garbage collection (due to classic) server should also be excluded for Classic server operations ;-]. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
