ITAGAKI Takahiro wrote: > I have some comments about the double-buffering:
Since posting this patch I have realized that this implementation is bogus. I'm now playing with WAL-logging hint bits though. As to your questions: > - Are there any performance degradation because of addtional memcpy? > 8kB of memcpy seems not to be free. Of course, it is not free. However it comes with the benefit that we can release the io_in_progress lock earlier for the block -- we lock, copy, unlock; whereas the old code did lock, write(), unlock. Avoding a system call in the locked area could be a win. Whether this is a net benefit is something that I have not measured. > - Is it ok to allocale dblbuf[BLCKSZ] as local variable? > It might be unaligned. AFAICS we avoid such usages in other places. 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 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. The point of double-buffering is that the potential writer (a process doing concurrent hint-bit setting) is not going to grab any locks. > - 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. Not sure on this. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
