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

Reply via email to