Re: checkpoint occurs very often when vacuum full running

Hi

> I mean basicly the wals should contain the changes, and vacuum full changes the location of the data and not actually the data.
Row location is data. For example, index lookup relies on TID (tuple id, hidden ctid column) - physical row address in datafile.
Postgresql WAL - it is about physical changes in datafiles (block level), not logical. Just moving one row to another place without logical changes means: mark row deleted in old place, write to new place and update every index which contains this row.
And vacuum full does not change location, it create copy in different datafile. Then it rebuild every index because TID was obviously changed. Then vacuum full drop old datafiles. Full size of new datafile and indexes should be written to WAL, because all of this is changes and must be reliable written (and then can be replayed on replicas).

> but I didn't find anything about it in the documentation
hmm, i can not found something exact in documentation about it.. It's my knowledge about postgresql internals.
You can read this article: https://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/ Its about WAL logic. All IO operations use pages, and difference between pages written to WAL.
For example, full_page_writes setting ( https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-FULL-PAGE-WRITES ) say about pages too.
> writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint.
If you want change few bytes in page - the whole page (8kb typical) will be written to WAL during first change of this page after checkpoint.

regards, Sergei