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 s
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
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 k
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 sugg
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:[E
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
> >
- 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
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 suggest
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
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 po
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 problem
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
>> >
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 th
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 pat
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
c
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 o
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?
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
> fo
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.
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 avai
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 f
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 a
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 abou
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
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 if
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
26 matches
Mail list logo
