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