Re: VACUUM FULL
От
Dan Langille
Тема
Re: VACUUM FULL
Дата
Msg-id
20010511204113.21CB03F3F@bast.unixathome.org
Ответ на
VACUUM FULL (Brian McCane)
Список
Дерево обсуждения
A couple of errors encountered in 7.1.3=>7.2.1-2 data migration "Nick Fankhauser" <nickf@ontko.com>
Re: A couple of errors encountered in 7.1.3=>7.2.1-2 data migration Tom Lane <tgl@sss.pgh.pa.us>
Re: A couple of errors encountered in 7.1.3=>7.2.1-2 data migration Ray Ontko <rayo@ontko.com>
Re: A couple of errors encountered in 7.1.3=>7.2.1-2 data migration Tom Lane <tgl@sss.pgh.pa.us>
Re: A couple of errors encountered in 7.1.3=>7.2.1-2 data migration "Nick Fankhauser" <nickf@ontko.com>
VACUUM FULL Brian McCane <bmccane@mccons.net>
Re: VACUUM FULL Tom Lane <tgl@sss.pgh.pa.us>
Re: VACUUM FULL "Dan Langille" <dan@langille.org>
Re: VACUUM FULL "Rajesh Kumar Mallah." <mallah@trade-india.com>
Re: VACUUM FULL Brian McCane <bmccane@mccons.net>
Re: VACUUM FULL "Rajesh Kumar Mallah." <mallah@trade-india.com>
On 10 May 2002 at 19:18, Brian McCane wrote:
> But, a 4% decrease in size should not add up to a 84% increase in
> performance (is that right? I always get the ratio confused :).
Have you tried an ANALYZE as well? It wasn't mentioned.
See http://www.postgresql.org/idocs/index.php?routine-vacuuming.html
PostgreSQL's VACUUM command must be run on a regular basis for several
reasons:
1. To recover disk space occupied by updated or deleted rows.
2. To update data statistics used by the PostgreSQL query planner.
3. To protect against loss of very old data due to transaction ID
wraparound.
Read 8.2.2. Updating planner statistics
--
Dan Langille
The FreeBSD Diary - http://freebsddiary.org/ - practical examples
В списке pgsql-admin по дате отправления