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
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 |