From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Profiling vs autovacuum (was Re: building 8.3beta2 w/ 'make check' consumes A LOT of disk space) |
Date: | 2007-11-04 03:06:21 |
Message-ID: | 4285.1194145581@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> However, accumulation of zillions of gmon.out files is definitely a
> downside of the approach; one that I've noticed myself. I've also
> noticed that it takes a heck of a long time to rm -rf $PGDATA once
> you've built up a few tens of thousands of gprof subdirectories. What's
> worse, this accumulation will occur pretty quick even if you're not
> doing anything with the DB, because of autovacuum process launches.
> I wonder if we need to rein in gmon.out accumulation somehow, and if
> so how? This isn't an issue for ordinary users but I can see it
> becoming a PITA for developers.
On reflection, it seems like the worst part of this is the steady
accumulation of gprof files from autovacuum workers, which are unlikely
to be of interest at all (if you want to profile vacuuming, you'd
probably issue manual vacuum commands anyway). So I propose something
like the attached, untested patch to force all AV workers to dump to the
same gmon.out file. Comments?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/plain | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-11-04 07:36:40 | Re: Profiling vs autovacuum |
Previous Message | Neil Conway | 2007-11-04 02:35:20 | "bad key in cancel request" |