From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Vacuum questions... |
Date: | 2005-09-25 00:17:38 |
Message-ID: | 20050925001738.GS7630@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Would it be difficult to vacuum as part of a dump? The reasoning behind
this is that you have to read the table to do the dump anyway, so it
would be a good time to be able to piggy-back other operations that need
to read the entire table on top. I know vacuuming of indexes complicates
this, so it's probably not as simple as just firing off a vacuum and
copy at the same time (although that idea is probably worth testing,
since it might still be a win).
When dropping a table or index, is it's space immediately released in
the FSM?
Also, would it be possible to add some means to check the status of a
running vacuum? Even with vacuum verbose, once it starts in on a large
table you have no way to know how far along it is.
Finally, if vacuum_delay is enabled, does vacuum_cost_page_miss consider
a miss as not in the database buffer, or not in the kernel buffer? I
remember discussions about trying to track IO request times to try and
determine if something came out of kernel buffers or not, but AFAIK
that's all vaporware right now...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2005-09-25 00:20:47 | Re: \d on database with a lot of tables is slow |
Previous Message | Jim C. Nasby | 2005-09-24 23:59:24 | \d on database with a lot of tables is slow |