Re: another query optimization question
От | David Teran |
---|---|
Тема | Re: another query optimization question |
Дата | |
Msg-id | 1DABF561-5432-11D8-84ED-000A95A6F0DC@cluster9.com обсуждение исходный текст |
Ответ на | Re: another query optimization question ("Marc G. Fournier" <scrappy@postgresql.org>) |
Список | 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
В списке pgsql-performance по дате отправления: