Daniel Griscom wrote:
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.
My estimate is that yes, you should definitely consider that.
I'm only running one query at a time; would that query be guaranteed
to confine itself to a single processor/core?
From what Joshua mentions, looks like you do have that guarantee.
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.
As I mentioned, the important thing is not really raw CPU power as
much as *responsiveness* --- that is what IMO the multi-core/multi-CPU
boosts the most. The thing is, to guarantee the required responsiveness
with a single-CPU-single-core you would have to increase the CPU
speed (the real speed --- operations per second) by a fraction
spectacularly
high, so that you that guarantee that the rendering will have the CPU
soon enough ... When maybe with even less raw CPU power, but
having always one of them ready to process the second task, you
reduce the latency to pretty much zero.
Someone suggested "setting the CPU costs higher"; where would I learn
about that?
Documentation --- look up the postgresql.conf file.
Someone else mentioned having a custom function that sleep()ed on
every row access; where would I learn more about that?
Documentation for server-side procedures (PL/PgSQL --- although as I
understand it, you can write server-side procedures in C, Perl, Java, and
others).
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?
I think it may depend on the version you're running --- but definitely, you
do want to run vacuum analyze (notice, not simply vacuum; you want a
vacuum analyze) often, and definitely after loading up a lot of new data.
(that is, you definitely want to run a vacuum analyze right away --- that
is, at the earliest opportunity)
HTH,
Carlos
--
