Re: 9.1 got really fast ;)

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alban Hertroys <haramrae(at)gmail(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(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 19:05:10
Message-ID: CAOR=d=0BGd_sW0r0MOi9Ktznwa-QY5unoHEedYQ5oE69An_DXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Oct 17, 2011 at 9:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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?

Could be. That machine has 48 AMD 61xx series cores in it.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Henry Drexler 2011-10-17 19:11:09 Re: Use true and false when bulk-exporting boolean data
Previous Message Viktor Rosenfeld 2011-10-17 18:29:24 Use true and false when bulk-exporting boolean data