* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [081001 19:42]:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > a) You wouldn't have to keep the lock while doing the I/O.
> 
> Hoo, yeah, so the period of holding the share-lock could well be
> *shorter* than it is now.  Most especially so if the write() blocks
> instead of just transferring the data to kernel space and returning.
> 
> I wonder whether that could mean that it's a win to double-buffer
> even if we aren't computing a checksum?  Nah, probably not.

That all depends on what you think is longer: copy 8K & release, or
syscall(which obviously does a copy)+return & release... And whether you
want to shorten the lock hold time (but it's only shared), or the time
until write is done (isn't the goal to have writes being done in the
background during checkpoint so write latency isn't a problem)...  This
might be an interesting experiment for someone to do with a very high
concurrency, high-write load...

a.


-- 
Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

In response to

• Re: Block-level CRC checks at 2008-10-01 23:41:24 from Tom Lane

Responses

• Re: Block-level CRC checks at 2008-10-02 05:29:57 from Jonah H. Harris

pgsql-hackers by date

Next:	From: Alvaro Herrera	Date: 2008-10-02 00:34:42
	Subject: Re: Transactions within a function body
Previous:	From: Tom Lane	Date: 2008-10-01 23:41:24
	Subject: Re: Block-level CRC checks