Em 25/02/2017 08:03, Mark Rotteveel escreveu: > On 25-2-2017 10:49, Dmitry Yemanov wrote: >> Depending on the plan, statement may take 99% of its "working" time >> inside execute() or inside fetch() or that time could be distributed >> among the API calls. Neither client nor DBA has any control on that. So >> I consider seriously wrong removing fetching time from the accounting. >> >> From the client side, a timeout can be seen from two different angles. >> It could be either statement execution time (including fetches, see >> above) - this is what we have implemented now. > > But it is not the execution time (which, in my view, is the time spent > in the engine) that is constrained by the current implementation - as I > understood it (correct my if I'm wrong) -, it is the total wall-clock > time which includes time 'waiting' on the user and doing nothing in the > server. >
It also seems server doing client jobs. This timeout will start counting when engine receives the query, but from client POV, it should start when client executes the statement. That makes a whole difference in network and small timeout in milliseconds. Adriano ------------------------------------------------------------------------------ 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
