Peter Nixon said:
Yep. This was something I added a couple of years ago because I realised that my report database was spending half of its time recalculating the the Session Time every time the report was rerun. Its much more efficient to do it once, and then just set the delay time to zero which gives the same end result to any reports/scripts that expect to have to calculate it itself.
Actually the thing I first noticed was that in accounting_start and _stop, it is still saving the Acct-Delay-Time, rather than setting it to 0 (I just double checked this in the latest 1.1.7 update). My thought was that it should do one or the other ... either apply the delay in the query and set the delay time to zero, or not apply the delay time and save the delay value. That was originally my question, then I noticed that the MySQL queries were different, and got kind of sidetracked. [much snippage]
If you still feel differently, please speak up, I am open to suggestions. No-one was taking much care of the postgresql code when I started using it about 6 years ago, so I just kinda adopted it and fixed/sped/cleaned things up as I ran into them. I really need to sit down and port it all across to the other DBs.. I did significant work on the default indexes also with performance tests on multi GB tables...
I don't disagree with anything you said. Horses for courses. I guess my main point was, the two sets of queries do different things. We might want to consider making them same-same, and squeeze those changes under the 1.1.7 wire. As usual, I'm happy to do the MySQL testing. And maybe resolve that "set delay to 0" thing, if we're applying the delay time in the queries.
Peter Nixon http://peternixon.net/
-- hugh