On Sun, 9 Nov 2003, Jan Wieck wrote:
scott.marlowe wrote:
On Fri, 7 Nov 2003, Matthew T. O'Connor wrote:
- Original Message -
From: Jan Wieck [EMAIL PROTECTED]
Tom Lane wrote:
Gaetano and a couple of other people did experiments that seemed to show
it was useful.
Yes, I would like to see the vacuum delay patch go into 7.4.1 if possible.
It's really useful. I don't think there is any major risk in adding the
delay patch into a minor revision given the small amount of code change.
Stephen
Matthew T. O'Connor [EMAIL PROTECTED] wrote in message
news:[EMAIL
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
However, I have not seen much evidence yet that the vacuum delay alone
does that much.
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later
scott.marlowe wrote:
On Fri, 7 Nov 2003, Matthew T. O'Connor wrote:
- Original Message -
From: Jan Wieck [EMAIL PROTECTED]
Tom Lane wrote:
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
Matthew T. O'Connor wrote:
- Original Message -
From: Jan Wieck [EMAIL PROTECTED]
Tom Lane wrote:
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later suggestions (sleep 10 ms every N
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as Gaetano pointed out
correctly, we will see wildforms with one or the other feature applied.
I'd believe that for
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian) wrote:
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as Gaetano pointed out
correctly, we
Christopher Browne wrote:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian) wrote:
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as
Christopher Browne wrote:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian) wrote:
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as Gaetano
Jan Wieck [EMAIL PROTECTED] writes:
However, I have not seen much evidence yet that the vacuum delay alone
does that much.
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later suggestions (sleep 10
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
However, I have not seen much evidence yet that the vacuum delay alone
does that much.
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later
- Original Message -
From: Jan Wieck [EMAIL PROTECTED]
Tom Lane wrote:
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later suggestions (sleep 10 ms every N blocks, instead of N ms every
On Fri, 7 Nov 2003, Matthew T. O'Connor wrote:
- Original Message -
From: Jan Wieck [EMAIL PROTECTED]
Tom Lane wrote:
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later
I've just uploaded
http://developer.postgresql.org/~wieck/all_performance.v4.74.diff.gz
This patch contains the still not yet ready performance improvements
discussed over the couple last days.
_Shared buffer replacement_:
The buffer replacement strategy is a slightly modified version of ARC.
Jan Wieck wrote:
_Vacuum page delay_:
Tom Lane's napping during vacuums with another tuning option. I
replaced the usleep() call with a PG_DELAY(msec) macro in miscadmin.h,
which does use select(2) instead. That should address the possible
portability problems.
What about skipping the delay
Jan Wieck [EMAIL PROTECTED] writes:
This patch contains the still not yet ready performance improvements
discussed over the couple last days.
Cool stuff!
The buffer replacement strategy is a slightly modified version of
ARC.
BTW Jan, I got your message about taking a look at the ARC code;
Manfred Spraul wrote:
Jan Wieck wrote:
_Vacuum page delay_:
Tom Lane's napping during vacuums with another tuning option. I
replaced the usleep() call with a PG_DELAY(msec) macro in miscadmin.h,
which does use select(2) instead. That should address the possible
portability problems.
What
Neil Conway wrote:
Jan Wieck [EMAIL PROTECTED] writes:
This patch contains the still not yet ready performance improvements
discussed over the couple last days.
Cool stuff!
The buffer replacement strategy is a slightly modified version of
ARC.
BTW Jan, I got your message about taking a look at
Jan Wieck wrote:
How portable is getrusage()? Could the postmaster issue that
frequently for RUSAGE_CHILDREN and leave the result somewhere in the
shared memory for whoever is concerned?
SVr4, BSD4.3, SUS2 and POSIX1003.1, I believe.
I also believe there is a M$ dll available that gives that
Andrew Dunstan wrote:
Jan Wieck wrote:
How portable is getrusage()? Could the postmaster issue that
frequently for RUSAGE_CHILDREN and leave the result somewhere in the
shared memory for whoever is concerned?
SVr4, BSD4.3, SUS2 and POSIX1003.1, I believe.
I also believe there is a M$ dll
On Wed, Nov 05, 2003 at 03:08:53PM -0500, Neil Conway wrote:
Jan Wieck [EMAIL PROTECTED] writes:
I personally would like to see this work included in a 7.4.x
release.
Personally, I can't see any circumstance under which I would view this
as appropriate for integration into the 7.4 branch
Jan Wieck [EMAIL PROTECTED] writes:
Manfred Spraul wrote:
What about skipping the delay if there are no outstanding disk
operations?
How portable is getrusage()? Could the postmaster issue that frequently
for RUSAGE_CHILDREN and leave the result somewhere in the shared memory
for whoever
On Wed, Nov 05, 2003 at 03:49:54PM -0500, Jan Wieck wrote:
Andrew Dunstan wrote:
Jan Wieck wrote:
How portable is getrusage()? Could the postmaster issue that
frequently for RUSAGE_CHILDREN and leave the result somewhere in the
shared memory for whoever is concerned?
SVr4, BSD4.3,
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as Gaetano pointed out
correctly, we will see wildforms with one or the other feature applied.
I'd believe that for patches of the size of my
Tom Lane wrote:
Manfred's idea is interesting but AFAICS completely unimplementable
in any portable fashion. You'd have to have hooks into the kernel.
I thought about outstanding operations from postgres - I don't know
enough about the buffer layer if it's possible to keep a counter of the
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as Gaetano pointed out
correctly, we will see wildforms with one or the other feature applied.
I'd believe that for
26 matches
Mail list logo
