On Tue, 8 May 2007, Daniel Griscom wrote:
Thanks for all the feedback. Unfortunately I didn't specify that this is
running on a WinXP machine (the 3D renderer is an ActiveX plugin), and I
don't even think "nice" is available. I've tried using the Windows Task
Manager to set every postgres.exe process to a low priority, but that didn't
make a difference.
Several people have mentioned having multiple processors; my current machine
is a uni-processor machine, but I believe we could spec the actual runtime
machine to have multiple processors/cores. I'm only running one query at a
time; would that query be guaranteed to confine itself to a single
processor/core?
In terms of performance, I don't think simply more power will do the trick;
I've got an AMD 3200+, and even doubling the power/halving the stutter time
won't be good enough.
Someone suggested "setting the CPU costs higher"; where would I learn about
that?
Someone else mentioned having a custom function that sleep()ed on every row
access; where would I learn more about that?
I've also been reading up on VACUUM. I haven't explicitly run it in the
several days since I've installed the database (by loading a humongous
data.sql file); might this be part of the performance problem?
it would cause postgres to work harder then it needs to, but it doesn't
solve the problem of postgres eating cpu that you need for your rendering
(i.e. it may reduce the stutters, but won't eliminate them)
a single query will confine itself to one core, but if you have a vaccum
or autovaccum run it will affect the second core.
I don't know what you can do on windows beyond this though.
David Lang
P.S. make sure you get real multi-core cpu's, hyperthreading is _not_ a
second core for this problem.
