Skip site navigation (1) Skip section navigation (2)

Re: Need help with 8.4 Performance Testing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: "jd(at)commandprompt(dot)com" <jd(at)commandprompt(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Jean-David Beyer <jeandavid8(at)verizon(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Need help with 8.4 Performance Testing
Date: 2008-12-09 22:38:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Scott Carey <scott(at)richrelevance(dot)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, and become almost irrelevant in 8.5's.
> Becoming more CPU efficient will become very important, and for some, already is.  The community needs to be proactive on this front.
> This turns a lot of old assumptions on their head, from the database down through the OS and filesystem.  We're bound to run into many surprises due to this major shift in something that has had its performance characteristics taken for granted 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.

			regards, tom lane

In response to


pgsql-performance by date

Next:From: David WilsonDate: 2008-12-09 22:41:33
Subject: Re: query plan with index having a btrim is different for strings of different length
Previous:From: Scott CareyDate: 2008-12-09 22:05:18
Subject: Re: Need help with 8.4 Performance Testing

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group