On Thu, 2007-01-25 at 11:03 -0500, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > ISTM that we would get the effect your looking for by just moving the
> > xl_tot_len field to the end, and only storing it for records with backup
> > blocks:
>
> I like that formulation bette
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> ISTM that we would get the effect your looking for by just moving the
> xl_tot_len field to the end, and only storing it for records with backup
> blocks:
I like that formulation better --- seems like less
change-for-the-sake-of-change.
On Thu, 2007-01-25 at 14:04 +, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
> > reduce this to 24 bytes, without reducing resilience, when
> > full_page_writes = off. This will reduce overall WAL volumes by around
> >
Simon Riggs wrote:
Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%, depending upon the application with performance gains in various
ways.
Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%, depending upon the application with performance gains in various
ways.
If full_page_writes
