Re: rapid degradation after postmaster restart

From: Joe Conway <mail(at)joeconway(dot)com>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: rapid degradation after postmaster restart
Date: 2004-03-16 05:48:05
Message-ID: 40569515.70902@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Matthew T. O'Connor wrote:
> Strange... I wonder if this is some integer overflow problem. There was
> one reported recently and fixed as of CVS head yesterday, you might try
> that, however without the -d2 output I'm only guessing at why
> pg_autovacuum is vacuuming so much / so often.

I'll see what I can do tomorrow to track it down.

I have already recommended to the program manager that they switch to
7.4.2 plus the autovacuum patch. Not sure they will be willing to make
any changes at this stage in their release process though.

> If we can't find one, any chance you can
> do some testing with CVS HEAD just to see if that works any better. I
> know there has been a fair amount of work done to improve this situation
> (not just vacuum delay, but ARC etc...)

I might do that, but not likely on Solaris. I can probably get a copy of
the current database and testing scripts, and give it a try on one of my
own machines (all Linux, either RHAS3, RH9, or Fedora).

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-03-16 05:52:14 Re: Confusion over Copy.c/Count rows from file patch
Previous Message Greg Stark 2004-03-16 05:39:39 Re: Reducing expression evaluation overhead

Browse pgsql-performance by date

  From Date Subject
Next Message Joe Conway 2004-03-16 07:11:35 Re: [PERFORM] rapid degradation after postmaster restart
Previous Message Joe Conway 2004-03-16 05:38:03 Re: rapid degradation after postmaster restart