Did you change anything else between 263 and 264? From the table it appears that you are changing vm parameters
as well as database configuration parameters between runs ?
Dave
Mark Wong wrote:
Yes, those parameters are based on a series of test results here: http://www.osdl.org/projects/dbt2dev/results/pgsql/rc4.html
Run 264 provided the best results, so I'm trying to continue with the database parameters used there.
Mark
On Wed, Mar 02, 2005 at 10:41:57AM -0500, Dave Cramer wrote:
I was just looking at the config parameters, and you have the shared buffers set to 60k, and the effective cache set to 1k ????
Dave
Mark Wong wrote:
On Tue, Mar 01, 2005 at 05:17:07PM -0500, Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
On Tue, Mar 01, 2005 at 04:57:11PM -0500, Tom Lane wrote:My point was that unpatched 8.0.1 seems to have a pretty level TPM
Curious. The immediate question is "does it ever flatten out, andThe comparison was against 8.0.1, or did you mean 8.0.1 with the 2Q
if so at what TPM rate compared to 8.0.1?" Could you run the same
test for a longer duration?
patch? I can run a longer duration and see how it looks.
rate. If the patched version levels out at something not far below
that, I'll be satisfied. If it continues to degrade then I won't be
satisfied ... but the test stops short of telling what will happen.
If you could run it for 2 hours then we'd probably know enough.
Ah, ok. I've reapplied the 2Q patch to CVS from 20050301: http://www.osdl.org/projects/dbt2dev/results/dev4-010/313/
I ran it for 3 hours, just in case, and the charts suggest it flattens out after 2 hours.
Mark
-- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
