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

> With DELETE FROM foo, let's suppose you have 10 pages in the table.
To
> modify page 1, you write to page 11

But what with the indexes ? They would all need to be modified
accordingly.
If you did something like chaining, then before long all tuples would be

chained, even those that were not touched.

If you really want to avoid the page writes to WAL, imho the best way
would be 
to revive the original PG page design where the physical position of
slots in a 
heap page where only changed by vacuum.

Then, a heap page that was only partly written would only be a problem
iff 
the hardware wrote wrong data, not if it only skipped part of the write.

Reasonable hardware does detect such corrupted pages.
E.g. on AIX if you reduce the PG pagesize to 4k, an only partly written
page 
that stays undetected can be ruled out.

Then you would only need to write index pages to WAL, but not heap
pages.

Maybe a better idea would be to only conditionally write pages to WAL if
slot 
positions changed. In the "delete" example heap slot positions certainly
do 
not need to change. 
To be extra safe it would probably be necessary to not split tuple
headers
(at least the xact info) across physical pages. Then it would also be
safe to 
use a pg pagesize that is a multiple of the physical page size.

or so ? ...
Andreas