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

Re: Vacuum time degrading

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Wes <wespvp(at)syntegra(dot)com>
Cc: Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Vacuum time degrading
Date: 2005-03-02 21:51:21
Message-ID: 14167.1109800281@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Wes <wespvp(at)syntegra(dot)com> writes:
> Watching the system as vacuum is running, I can see that we are encountering
> the kswapd/kscand problem in the 2.4.20 kernel.  This could very well
> account for the non-linear increase in vacuum time.

Hmm.  Looking at the vacuum verbose output you sent me, it's clear that
the bulk of the time is going into scanning a couple of the larger
indexes.  On an index that's been growing for awhile, this involves a
highly nonsequential access pattern (it wants to visit the index leaf
pages in sort order, which will not look much like physical order after
a lot of page splits have occurred).  I don't know whether that would
tend to set off the kswapd/kscand problems, but just in terms of
physical I/O time it might be annoying.  I was going to suggest
REINDEXing those indexes to see if that cuts the vacuum time at all.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Mark WongDate: 2005-03-02 22:15:37
Subject: Re: 8.0.X and the ARC patent
Previous:From: pgsqlDate: 2005-03-02 21:38:28
Subject: Re: [pgsql-hackers-win32] snprintf causes regression

pgsql-general by date

Next:From: Martijn van OosterhoutDate: 2005-03-02 21:59:22
Subject: Re: Index size
Previous:From: WesDate: 2005-03-02 21:31:12
Subject: Re: Vacuum time degrading

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