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
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 |
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 |