On Fri, 2005-03-04 at 20:10 -0500, Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Amdahl's Law tells me that looking at the checkpoints is the next best
action for tuning, since they add considerably to the average response
time. Looking at the oprofile for the run as a whole is
Simon Riggs [EMAIL PROTECTED] writes:
The checkpoints are the source of the peak latency on transactions, so we
are in complete agreement.
I realize that. I was just supporting your conclusion but saying that latency
is important in its own right, not just as a means to achieving throughput.
On Wed, 2005-03-02 at 20:55 -0500, Tom Lane wrote:
Michael Adler [EMAIL PROTECTED] writes:
Looking at the Response Time Charts
8.0.1/ARC
http://www.osdl.org/projects/dbt2dev/results/dev4-010/309/rt.html
20050301 with 2Q patch
Simon Riggs [EMAIL PROTECTED] writes:
Checkpoint doesn't request new buffers, but it does require the
BufMgrLock in order to write all of the dirty buffers.
There is no BufMgrLock anymore in the clock-algorithm code, so I'm not
sure how much of this analysis is still relevant.
Simon Riggs [EMAIL PROTECTED] writes:
Amdahl's Law tells me that looking at the checkpoints is the next best
action for tuning, since they add considerably to the average response
time. Looking at the oprofile for the run as a whole is missing out the
delayed transaction behaviour that
Dave Cramer [EMAIL PROTECTED] writes:
I was just looking at the config parameters, and you have the shared buffers
set to 60k, and the effective cache set to 1k
I was actually going to suggest that the performance degradation might be
because of an excessively high shared_buffers setting.
Josh Berkus josh@agliodbs.com writes:
I should be able to run more OLTP benchmarks, and a DSS benchmark, within the
next week. Please wait until I complete those before considering an 8.0.2
release with the new code.
Sure, there's no hurry to push out 8.0.2 (and we need to have some beta
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:
Curious. The immediate question is does it ever flatten out, and
if so at what TPM rate compared to 8.0.1? Could you run the same
test
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,
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
OK. I doubt that it impacts the results of the particular test, but it
is non-intuitive (in my mind at least)
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
On Wed, Mar 02, 2005 at 07:21:41AM -0800, Mark Wong wrote:
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.
Looking at the
Mark Wong [EMAIL PROTECTED] writes:
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.
Thanks. This seems odd though, since it
On Wed, Mar 02, 2005 at 03:15:54PM -0500, Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
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
Between those two runs, the vm parameters are the same.
Mark
On Wed, Mar 02, 2005 at 11:04:21AM -0500, Dave Cramer wrote:
OK. I doubt that it impacts the results of the particular test, but it
is non-intuitive (in my mind at least)
Did you change anything else between 263 and 264? From the
Mark Wong [EMAIL PROTECTED] writes:
On Wed, Mar 02, 2005 at 03:15:54PM -0500, Tom Lane wrote:
Thanks. This seems odd though, since it appears to level out at
something above 4K TPM. Your previous run
http://www.osdl.org/projects/dbt2dev/results/dev4-010/311/
shows it dropping to 3500 or so.
Michael Adler [EMAIL PROTECTED] writes:
Looking at the Response Time Charts
8.0.1/ARC
http://www.osdl.org/projects/dbt2dev/results/dev4-010/309/rt.html
20050301 with 2Q patch
http://www.osdl.org/projects/dbt2dev/results/dev4-010/313/rt.html
It seems like the average response time has
Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
On Wed, Mar 02, 2005 at 03:15:54PM -0500, Tom Lane wrote:
Thanks. This seems odd though, since it appears to level out at
something above 4K TPM. Your previous run
http://www.osdl.org/projects/dbt2dev/results/dev4-010/311/
shows it
Tom,
I should be able to run more OLTP benchmarks, and a DSS benchmark, within the
next week. Please wait until I complete those before considering an 8.0.2
release with the new code.The machine and setup Mark is testing on is
kind of end-of-the-curve; I have some more middle-of-the-road
On Sat, Feb 19, 2005 at 12:57:52AM -0500, Tom Lane wrote:
So far I've not been able to measure any consistent difference, but you
know how much I trust pgbench ;-). I hope that Mark Wong can give us
some results on the OSDL setup soon.
Sorry for the delay, broken laptop, vacation, etc.
Mark Wong [EMAIL PROTECTED] writes:
About a 6% increase, but if you look at the performance over time,
it's degrading steadily. The latter throughput peaks near 5000.
Curious. The immediate question is does it ever flatten out, and
if so at what TPM rate compared to 8.0.1? Could you run the
On Tue, Mar 01, 2005 at 04:57:11PM -0500, Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
About a 6% increase, but if you look at the performance over time,
it's degrading steadily. The latter throughput peaks near 5000.
Curious. The immediate question is does it ever flatten out,
Mark Wong [EMAIL PROTECTED] writes:
On Tue, Mar 01, 2005 at 04:57:11PM -0500, Tom Lane wrote:
Curious. The immediate question is does it ever flatten out, and
if so at what TPM rate compared to 8.0.1? Could you run the same
test for a longer duration?
The comparison was against 8.0.1, or
Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for Beta
On Fri, 2005-02-25 at 02:47 -0400, Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle
On Fri, 2005-02-25 at 00:18 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
Marc G. Fournier [EMAIL PROTECTED] writes:
Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.
I thought we were looking at a 12-18 month cycle for 8.1? Which would put
beta
Tom Lane wrote:
Although we've dropped the idea of letting the ARC problem drive a very
short 8.1 cycle, I would still like to see us shoot for a relatively
short 8.1 cycle --- less than a year for sure. The main reason is that
I think we'll be flushing out performance and feature issues in the
Matthew T. O'Connor matthew@zeut.net writes:
One thing to consider while discussing the length of the cycle is what
features are people planning on putting in? The 8.0 cycle had to be
long due to the many huge improvements. I'm not aware of any 8.1 plans
that are that ambitious, so why
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.
I thought we were looking at a 12-18 month cycle for 8.1?
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for Beta freeze for 8.1 then?
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for Beta freeze for 8.1 then?
September 30th 2005 ?
I see
Tom Lane wrote:
Still to be determined: what we lose in extra I/O from the presumably
less efficient cache management; also what sort of slowdown occurs on
a single-CPU machine that isn't going to get any benefit from the
increased amount of lock management. But it looks promising.
Yea, that
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Still to be determined: what we lose in extra I/O from the presumably
less efficient cache management; also what sort of slowdown occurs on
a single-CPU machine that isn't going to get any benefit from the
increased amount of lock
FYI, core has discussed the pending IBM ARC patent and the usage of
those ideas in 8.0.
Tom has found a 2Q cache algorithm that predates the ARC patent and is
very similar to ARC. The major difference is that it doesn't auto-size
the ARC sub-buffers.
Core believes it is best to backpatch this
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-write the code, but it
would also be sort of an
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-write the code,
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-write the code,
Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to
Joshua D. Drake wrote:
Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an
[EMAIL PROTECTED] writes:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
If there were hard evidence that the ARC algorithm was far better than
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
If there were hard evidence that the ARC
Bruce Momjian pgman@candle.pha.pa.us writes:
And ARC has locking requirements that will make it very hard to fix our
SMP buffer management problems in 8.1.
I am working on a buffer manager rewrite using the BufMgrLock breakup
and clock sweep management algorithm we've been discussing. At the
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to
46 matches
Mail list logo
