From: | David Teran <david(dot)teran(at)cluster9(dot)com> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 21:12:03 |
Message-ID: | 1DABF561-5432-11D8-84ED-000A95A6F0DC@cluster9.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
> 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
>
I will try to check this on my system.
But here another hint, maybe more interesting for Apple though: The bug
does -not- occur if another process uses a lot of CPU time. We encoded
a quicktime movie into mpeg2 and while this was using about 90% and
while encoding the vcd i wanted to show the bug to a friend and it did
not work.
But besides this, is there any chance that we can optimize our initial
performance problem ;-)
regards David
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2004-02-02 09:48:21 | Re: views? |
Previous Message | Marc G. Fournier | 2004-01-31 20:15:35 | Re: another query optimization question |