Re: double-buffering page writes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: double-buffering page writes
Date: 2008-10-23 16:54:22
Message-ID: 10674.1224780862@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Alvaro Herrera wrote:
>> I thought about that too. I admit I am not sure if this really works
>> portably; however I don't want to add a palloc() to that routine.

> It should work, AFAIK, but unaligned memcpy()s and write()s can be a
> significantly slower. There can be only one write() happening at any
> time, so you could just palloc() a single 8k buffer in TopMemoryContext
> in backend startup, and always use that.

Some time ago, we arranged for shared buffers to be aligned on *more*
than maxalign boundaries (cf BUFFERALIGN) because on at least some
platforms this makes a very significant difference in the speed of
copying to/from kernel space. If you are going to double-buffer it
is going to be important to have the intermediate buffer just as well
aligned. A local char array won't be acceptable, and even for a
palloc'd one you'll need to take some extra steps (like wasting
ALIGNOF_BUFFER extra bytes so you can align the pointer palloc gives).

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-10-23 17:11:24 Re: [HACKERS] Hot Standby utility and administrator functions
Previous Message Simon Riggs 2008-10-23 16:50:51 Re: Block level concurrency during recovery