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

Re: Huge number of disk writes after migration to 8.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Marcin <migor(at)op(dot)pl>, pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: Huge number of disk writes after migration to 8.1
Date: 2006-01-18 03:54:31
Message-ID: 4197.1137556471@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-patches
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Looking at the code, stats entries for dropped tables are cleaned out
>> only when a VACUUM command is done; which is something we probably ought
>> to change.

> I was going to ask if you were confusing pgstat_vacuum_tabstat with a
> VACUUM command, when I noticed that only in vacuum() is that function
> called!  This surprised me and I agree that it should be changed.  I'm
> not sure what would be a more appropiate place to call it, however.

I don't have a problem with that.  What I'm thinking is that a DROP
TABLE command should issue a tabpurge message for the specific table
(or index) being zapped.  We still need vacuum_tabstat as a backstop
in case the tabpurge message gets lost, though.

Another thought is that in autovacuum, pgstat_vacuum_tabstat is really
called too often: once per autovac cycle would be sufficient, but
instead it's repeated for each table we vacuum.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: stephanieDate: 2006-01-18 07:49:14
Subject: BUG #2179: psql can't show chinese
Previous:From: Alvaro HerreraDate: 2006-01-18 00:51:05
Subject: Re: Huge number of disk writes after migration to 8.1

pgsql-patches by date

Next:From: Tom LaneDate: 2006-01-18 04:23:56
Subject: Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards
Previous:From: Greg Sabino MullaneDate: 2006-01-18 01:07:57
Subject: Re: New pg_dump options: exclude tables/schemas, multiple all, wildcards

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