Re: 9.1 got really fast ;)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: Steve Crawford <scrawford(at)pinpointresearch(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: 9.1 got really fast ;)
Date: 2011-10-17 15:44:34
Message-ID: 14474.1318866274@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Szymon Guz 2011-10-17 16:57:28 Re: index bloat question
Previous Message Merlin Moncure 2011-10-17 15:33:16 Re: plpgsql; execute query inside exists