Skip site navigation (1) Skip section navigation (2)

Re: problems with new vacuum (??)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: problems with new vacuum (??)
Date: 2002-01-02 18:12:03
Message-ID: 200201021812.g02IC3q09418@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Barry Lind <barry(at)xythos(dot)com> writes:
> > But while this vacuum was running the rest of the system was performing 
> > very poorly.  Opperations that usually are subsecond, where taking 
> > minutes to complete.
> 
> Is this any different from the behavior of 7.1 vacuum?  Also, what
> platform are you on?
> 
> I've noticed on a Linux 2.4 box (RH 7.2, typical commodity-grade PC
> hardware) that vacuum, pgbench, or almost any I/O intensive operation
> drives interactive performance into the ground.  I have not had an
> opportunity to try to characterize the problem, but I suspect Linux's
> disk I/O scheduler is not bright enough to prioritize interactive
> operations.

Just as a data point, I have not seen pgbench dramatically affect
performance on BSD/OS.  Interactive sessions are just slightly slower
when then need to access the disk.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-01-02 18:13:32
Subject: Re: problems with new vacuum (??)
Previous:From: Holger KrugDate: 2002-01-02 17:58:31
Subject: Re: Feature proposal: generalizing deferred trigger events

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group