> > > > I would expect high-level transaction redo records to be much more
> > > > compact; mixed into the WAL, such records shouldn't make the WAL
> > > > grow much faster.
> >
> > All redo records have to be at the tuple level, so what higher-level
> > are you talking about ? (statement level redo records would not be
> > able to reproduce the same resulting table data (keyword: transaction
> > isolation level))
>
> Statement-level redo records would be nice, but as you note they are
> rarely practical if done by the database.
>
> Redo records that contain that contain whole blocks may be much bulkier
> than records of whole tuples. Redo records of whole tuples may be much
> bulkier than those that just identify changed fields.
>
> Bulky logs mean more-frequent snapshot backups, and bulky log formats
> are less suitable for network transmission, and therefore less useful
> for replication. Smaller redo records take more processing to generate,
> but that processing can be done off-line, and the result saves other
> costs.
Tom has identified that VACUUM generates hug WAL traffic because of the
writing of page preimages in case the page is partially written to disk.
It would be nice to split those out into a separate WAL file _except_ it
would require two fsyncs() for commit (bad), so we are stuck. Once the
page is flushed to disk after checkpoint, we don't really need those
pre-images anymore, hence the spliting of WAL page images and row
records for recovery purposes.
In other words, we keep the page images and row records in one file so
we can do one fsync, but once we have written the page, we don't want to
store them for later point-in-time recovery.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
