> > --------------- > > The feature could be useful for: > > - database administrators get instrument to limit heavy queries from > > consuming too much resources > > The problem is that long running transactions does not always equate to > "heavy queries". > > (1) A NATURAL SELECT which returns 1M rows that a client fetches over 120 > minutes is completely different from (2) a SELECT that executes for 120 > minutes and returns nothing (cus the SELECT is invalid/badly constructed) > > While the long transaction time of (1) does have a 'cost' when it comes to > garbage collection, etc. > > From an operational perspective, IMO, it is cases like (2) which are more > important to catch.
I don't know what happened but the line above was showed as quoted from Vlad posts, that was not the case. The last part of my post should have read: >From an operational perspective, IMO, it is cases like (2) which are more >important to catch. Why more? Because (2) is entirely consuming a single CPU, likely creating a significant amount of disk IOs and thus is having a direct impact on the performance of other connections. ------------------------------------------------------------------------------ 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
