Skip site navigation (1) Skip section navigation (2)

Re: another query optimization question

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Teran <david(dot)teran(at)cluster9(dot)com>,Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: another query optimization question
Date: 2004-01-31 20:15:35
Message-ID: 20040131161128.N63159@ganymede.hub.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Sat, 31 Jan 2004, Tom Lane wrote:

> David Teran <david(dot)teran(at)cluster9(dot)com> writes:
> > Apple provides a little tool that can enable / disable the l2 cache ...
> > one CPU of a dual CPU system on the fly. When i start the testapp with
> > two CPU's enabled i get this output here, when i turn off one CPU while
> > the app is still running the messages disappear as long as one CPU is
> > turned off. Reactivating the CPU again produces new error messages.
>
> Ah-hah, so the gettimeofday bug *is* linked to multiple CPUs.  Marc,
> were the machines you saw it on all multi-CPU?

I'm not sure ... I thought I ran it on my P4 here in the office and saw it
too, albeit not near as frequently ... but, in FreeBSD's case, it is a
"design issue" ... there are two different functions, once that is kinda
fuzzy (but fast), and the other that is designed to be exact, but at a
performance loss ... or was it the same function, but a 'sysctl' variable
that changes the state?

Can't remember which, but it is by design on FreeBSD ... and, if we're
talking about Apple, the same most likely applies, as its based on the
same kernel ...

Back of my mind, I *think* it was these sysctl variables:

kern.timecounter.method: 0
kern.timecounter.hardware: i8254



 ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org           Yahoo!: yscrappy              ICQ: 7615664

In response to

Responses

pgsql-performance by date

Next:From: David TeranDate: 2004-01-31 21:12:03
Subject: Re: another query optimization question
Previous:From: Bruce MomjianDate: 2004-01-31 18:40:24
Subject: Re: High Performance/High Reliability File system on SuSE64

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group