Re: Block-level CRC checks

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql(at)mohawksoft(dot)com, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Decibel! <decibel(at)decibel(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 00:17:40
Message-ID: 20081002001740.GJ16893@yugib.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* 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

Responses

Browse pgsql-hackers by date

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