From: | Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com> |
---|---|
To: | Chris Travers <chris(dot)travers(at)gmail(dot)com> |
Cc: | Grzegorz Jaskiewicz <gryzman(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-16 21:40:51 |
Message-ID: | CAP_rwwn4vWjhdaMs2Vp+ZSwXE0Q1Fw9-sUNQhUKvYjRO3Sg_PQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2011/10/15 Chris Travers <chris(dot)travers(at)gmail(dot)com>
>
>
> On Sat, Oct 15, 2011 at 1:33 PM, Grzegorz Jaskiewicz <gryzman(at)gmail(dot)com>wrote:
>
>>
>> On 15 Oct 2011, at 21:20, Thomas Kellerer wrote:
>> >
>> > Total runtime: -2.368 ms <<==== this is amazing ;)
>> >
>> > This is with 9.1.1 on a Windows XP machine
>>
>> Are you saying that Windows XP is the ultimate server OS for high
> performance PostgreSQL installations? Are there optimizations that this
> platform can take advantage of, perhaps extending Pg timelines into actual
> time travel that are not available on other platforms?
>
In some way, time travel is possible - system clock can be adjusted, think:
ntpd
That triggers another question:
Is PostgreSQL internal timing somehow immune to system clock backward "step"
("slew" should be safe) issued by ntpd?
Can it be "fixed" so it at least does not return nagative time deltas?
For definition of "step" vs "slew", see
http://osr507doc.sco.com/en/NetAdminG/ntpC.ntp_terms.html
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2011-10-16 23:17:09 | Re: 9.1 got really fast ;) |
Previous Message | Szymon Guz | 2011-10-16 20:41:44 | index bloat question |