From: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Where does vacuum FULL write temp-files? |
Date: | 2015-04-15 08:46:47 |
Message-ID: | VisenaEmail.f.3d26bd731306777a.14cbc403be3@tc7-visena |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
På onsdag 15. april 2015 kl. 04:34:31, skrev Venkata Balaji N <nag1010(at)gmail(dot)com
<mailto:nag1010(at)gmail(dot)com>>: I'm planning to vacuum FULL a pg_largeobject
relation (after vacuumlo'ing it). The relation is 300GB large so I'm concerned
the operation will write full my pg_xlog directory which is on a 200GB (net)
RAID1 SSD. Where does vacuum FULL rewrite to, does it use pg_xlog or some
other directory? Which version of PostgreSQL is this ?
If i got your question correctly, VACUUM FULL would rewrite the data to a
new data file associated with that particular relation (Table) in the
"$PGDATA/base" directory. This needs an extra disk space at the OS level (this
is not related to pg_xlog directory).
As VACUUMING is a data change operation, "pg_xlog" will also have only the
WAL data (modifications) written at the time of VACUUMING.
http://www.postgresql.org/docs/9.4/static/sql-vacuum.html
<http://www.postgresql.org/docs/9.4/static/sql-vacuum.html> This is PG-9.3
So I understand that VACUUM FULL writes the new table to the same tablespace as
the original table (also for system-catalogs like pg_largeobject), and doesn't
use any temp-space outside the location of that tablespace? Thanks. --
Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963
andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com> www.visena.com
<https://www.visena.com> <https://www.visena.com>
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Joseph Krogh | 2015-04-15 08:49:01 | Re: How to keep pg_largeobject from growing endlessly |
Previous Message | Venkata Balaji N | 2015-04-15 02:43:47 | Re: How to keep pg_largeobject from growing endlessly |