Re: TOAST performance (was Re: [GENERAL] Delete Performance)

If "pre-page WAL write" means the value of the page before the current
changes, then there is generally another reason for writing it out.

Imagine this sequence of events:
1. transaction A starts
2. transaction B starts
3. tran A makes a change
4. tran B makes a change
5. tran A commits
6. all changes get written to disk (this can happen even without fsync,   for example tran C might do a full table scan
whichfills the buffer cache   before B commits)
 
7. the system crashes

When the system comes back up, we need to do a rollback on
transaction B since it did not commit and we need the "pre-page"
to know how to undo the change for B that got saved in step 6 above.

At least this is what happens in most DBMSs...

Brian Beuning



Bruce Momjian wrote:

> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Is it because we take a snapshot of the page before we write it in case
> > > we only write part of the page?
> >
> > AFAIR, the partial-page-write problem is the entire reason for doing it.
> > If we could be certain that writes to datafile pages were atomic, we'd
> > not need this.
> >
> > Of course we can't be certain of that.  But I'm wondering if there isn't
> > a cheaper solution.
>
> I have added these TODO items to summarize this discussion:
>
> * Reduce number of pre-page WAL writes; they exist only to gaurd against
>   partial page writes
> * Turn off pre-page writes if fsync is disabled (?)
>
> --
>   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, Pennsylvania 19026
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)