From: | Steve Poe <spoe(at)sfnet(dot)cc> |
---|---|
To: | Chris Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Read/Write block sizes |
Date: | 2005-08-24 01:25:43 |
Message-ID: | 1124846743.12045.94.camel@amd64-laptop-spoe |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Chris,
Unless I am wrong, you're making the assumpting the amount of time spent
and ROI is known. Maybe those who've been down this path know how to get
that additional 2-4% in 30 minutes or less?
While each person and business' performance gains (or not) could vary,
someone spending the 50-100h to gain 2-4% over a course of a month for a
24x7 operation would seem worth the investment?
I would assume that dbt2 with STP helps minimize the amount of hours
someone has to invest to determine performance gains with configurable
options?
Steve Poe
> If someone spends 100h working on one of these items, and gets a 2%
> performance improvement, that's almost certain to be less desirable
> than spending 50h on something else that gets a 4% improvement.
>
> And we might discover that memory management improvements in Linux
> 2.6.16 or FreeBSD 5.5 allow some OS kernels to provide some such
> improvements "for free" behind our backs without *any* need to write
> database code. :-)
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-08-24 02:11:58 | Re: Caching by Postgres |
Previous Message | Jeffrey W. Baker | 2005-08-23 23:44:10 | Re: Read/Write block sizes (Was: Caching by Postgres) |