On Tue, 2008-12-09 at 17:38 -0500, Tom Lane wrote:
> Scott Carey <scott@richrelevance.com> writes:
> > Which brings this back around to the point I care the most about:
> > I/O per second will diminish as the most common database performance limiting factor in Postgres 8.4's lifetime,
andbecome almost irrelevant in 8.5's.
> > Becoming more CPU efficient will become very important, and for some, already is. The community needs to be
proactiveon this front.
> > This turns a lot of old assumptions on their head, from the database down through the OS and filesystem. We're
boundto run into many surprises due to this major shift in something that has had its performance characteristics taken
forgranted for decades.
>
> Hmm ... I wonder whether this means that the current work on
> parallelizing I/O (the posix_fadvise patch in particular) is a dead
> end. Because what that is basically going to do is expend more CPU
> to improve I/O efficiency. If you believe this thesis then that's
> not the road we want to go down.
The per cpu performance increase against the per I/O system increase
line is going to be vastly different. Anything that reduces overall I/O
is going to help (remember, you can never go too fast).
The idea that somehow I/O per second will diminish as the most common
database performance factor is IMO a pipe dream. Even as good as SSDs
are getting, they still have to go through the bus. Something CPUs are
better at (especially those CPUs that connect to memory directly without
the bus).
In 5 years maybe, in the next two postgresql releases, not likely. Not
to mention all of this is around the idea of a different class of
hardware than 99% of our community will be running.
Sincerely,
Joshua D. Drake
>
> regards, tom lane
>
--
PostgreSQL
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997