Re: another query optimization question

Поиск
Список
Период
Сортировка
Искать
От
David Teran
Тема
Re: another query optimization question
Дата
Msg-id
1DABF561-5432-11D8-84ED-000A95A6F0DC@cluster9.com
Ответ на
Список
Дерево обсуждения
another query optimization question David Teran <david.teran@cluster9.com>
Re: another query optimization question Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: another query optimization question David Teran <david.teran@cluster9.com>
Re: another query optimization question Tom Lane <tgl@sss.pgh.pa.us>
Re: another query optimization question David Teran <david.teran@cluster9.com>
Re: another query optimization question Tom Lane <tgl@sss.pgh.pa.us>
Re: another query optimization question David Teran <david.teran@cluster9.com>
Re: another query optimization question Tom Lane <tgl@sss.pgh.pa.us>
Re: another query optimization question "Marc G. Fournier" <scrappy@postgresql.org>
Re: another query optimization question David Teran <david.teran@cluster9.com>
Re: another query optimization question Richard Huxton <dev@archonet.com>
Re: another query optimization question PC Drew <drewpc@ibsncentral.com>
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

В списке pgsql-performance по дате отправления
От: Marc G. Fournier
Дата:
От: Richard Huxton
Дата:
Сообщение: Re: views?
FAQ