Re: 9.1 got really fast ;)

At 11:44 PM 10/17/2011, Tom Lane wrote:
>Alban Hertroys <haramrae(at)gmail(dot)com> writes:
> > On 17 October 2011 17:25, Steve Crawford
> <scrawford(at)pinpointresearch(dot)com> wrote:
> >> Even stand-alone statements take place within a transaction - just not an
> >> explicit one.
>
> > I doubt that more than 2.368 ms passed between the start of a
> > transaction and the stand-alone statement it's wrapping though. Not
> > impossible, but clock skew seems more likely to me.
>
>We take some pains to ensure that the same gettimeofday reading is used
>for both a transaction's start timestamp and the statement timestamp of
>its first statement. So I'm not sure what's up with Scott's report.
>But in the OP's EXPLAIN case, that's the difference between successive
>readings taken within the EXPLAIN code, so it's hard to see how to
>explain it in any other way than "your system clock went backwards".
>Possibly the underlying cause is clock skew between different processors
>on a multiprocessor machine?

Some years ago the early Athlon Athlon X2 CPUs had unsynced TSCs and
the OSes used the TSCs to speed up gettimeofday (somehow despite all
the advances in CPUs, chipsets etc, billions of transistors the
hardware bunch didn't help much for time keeping, yes there's HPET on
some motherboards but HPET isn't that great either AFAIK ).

I suppose this might be due to a different but still similar issue.

References:
<http://developer.amd.com/Membership/Print.aspx?ArticleID=38&web=http%3A%2F%2Fdeveloper.amd.com>http://developer.amd.com/Membership/Print.aspx?ArticleID=38&web=http%3A%2F%2Fdeveloper.amd.com

http://people.redhat.com/mingo/time-warp-test/time-warp-test.c

Regards,
Link.