Hi Laurenz.
thank you for the explanation but I still got a few questions about this subject :
1.By physical location of the data do you mean the location on disk of the objects ? I mean i thought that the wal files containing the logical changes , for example If I run an update then the wal file will contain the update in some format. Can you explain then what exactly it contains and what you meant by physical ?
2.So If the vacuum full stopped in some brutal way (kill -9 or the disk run of space) does all the new data files that are created deleted or left on the storage as orphan files ?
Thanks, Mariel.
בתאריך יום ה׳, 15 בנוב׳ 2018 ב-22:32 מאת Laurenz Albe <laurenz.albe@xxxxxxxxxxx>:
Mariel Cherkassky wrote:
> First of all thank you for the quick answer. In my case checkpoint happened
> every one second during the vacuum full so the checkpoint timeout isn't relevant.
> My guess was that it writes the changes to the wals but I didn't find anything
> about it in the documentation. Can you share a link that proves it ?
> I mean basicly the wals should contain the changes, and vacuum full changes
> the location of the data and not actually the data.
VACUUM (FULL) completely rewrites all the tables and indexes, so the complete
database will go into the WAL (these data changes have to be replayed in case
of a crash!). WAL contains the physical and not the logical changes, and the
physical data *are* modified.
You should let autovacuum do the job instead of running VACUUM (FULL), unless
your whole database is bloated beyond tolerance. That will cause less WAL
activity and also won't disrupt normal database operation.
If you really need that VACUUM (FULL), you can increase "max_wal_size" to
get fewer checkpoints.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
