postgres vs mysql start / stop times

[Hugh Messenger]

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