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)alvh(dot)no-ip(dot)org>
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: Huge number of disk writes after migration to 8.1
Date: 2006-01-18 18:14:36
Message-ID: 24124.1137608076@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-patches

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Tom Lane wrote:
>> Given the nature of what's counted, I think that treating these
>> messages as "row level" stats would be appropriate. Alvaro, what do
>> you think?

> Yeah, row level seems appropiate for what we use it. I'll take care of
> it, unless you want to do it.

Actually, there's another problem here: if we do have row-level stats
turned on, a manual "VACUUM" command will still cause the set of tables
listed in the stats file to grow to include every table in the DB,
whether or not anything interesting is happening to that table. I think
this is probably undesirable. I'm tempted to change pgstat_recv_vacuum
and pgstat_recv_analyze so that they will not create new hash entries,
but only insert the row count if the hash entry already exists. I am a
bit worried that I might be missing something about possible
interactions with autovacuum though. I see that autovac skips vacuuming
tables that have no hash entry ... is there some circular reasoning
going on there?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Marcin 2006-01-18 18:23:03 Re: Huge number of disk writes after migration to 8.1
Previous Message Thomas Goerner 2006-01-18 17:10:00 BUG #2181: Bug in SQLNumResultCols

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2006-01-18 18:32:55 Re: Huge number of disk writes after migration to 8.1
Previous Message Tom Lane 2006-01-18 16:44:37 Re: Huge number of disk writes after migration to 8.1