Alvaro Herrera <[EMAIL PROTECTED]> wrote: > I'm trying to see if it makes sense to do the double-buffering of page > writes before going further ahead with CRC checking. I came up with the > attached patch; it does the double-buffering inconditionally, because as > it was said, it allows releasing the io_in_progress lock (and resetting > BM_IO_IN_PROGRESS) early.
I have some comments about the double-buffering: - Are there any performance degradation because of addtional memcpy? 8kB of memcpy seems not to be free. - Is it ok to allocale dblbuf[BLCKSZ] as local variable? It might be unaligned. AFAICS we avoid such usages in other places. - It is the best if we can delay double-buffering until locks are conflicted actually. But we might need to allocale shadow buffers from shared buffers instead of local memory. - Are there any other modules that can share in the benefits of double-buffering? For example, we could avoid avoid waiting for LockBufferForCleanup(). It is cool if the double-buffering can be used for multiple purposes. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
