On Wed, Jun 07, 2006 at 09:34:47AM +0800, Qingqing Zhou wrote:
Qingqing Zhou [EMAIL PROTECTED] wrote
The overall performance improvement might be marginal but why not if it is
right. What I cares is the correctness. As I understand, the orginal code
puts a shared lock (1) to prevent the
Jim C. Nasby [EMAIL PROTECTED] wrote
Maybe a comment patch would be in order to prevent future confusion?
Not really needed because the buffer/README access rule#1 has already said
that ...
Regards,
Qingqing
---(end of broadcast)---
TIP 5:
Qingqing Zhou [EMAIL PROTECTED] wrote
The overall performance improvement might be marginal but why not if it is
right. What I cares is the correctness. As I understand, the orginal code
puts a shared lock (1) to prevent the vacuum process to move tuples around
so the hint bits change may
Attached is a patch to remove the lock protection for
HeapTupleSatisfiesVacuum() in index code. The basic idea is: if we can do
a pin/lock/unlock sequence on a page, then without locking again, we are
gauranteed that there is no vacuum process acting on the same page.
According to buffer pool
Qingqing Zhou [EMAIL PROTECTED] writes:
Attached is a patch to remove the lock protection for
HeapTupleSatisfiesVacuum() in index code.
This patch scares the heck out of me. You need to offer some pretty
compelling performance reasons before I'd accept any part of it,
most especially this:
Tom Lane [EMAIL PROTECTED] wrote
This patch scares the heck out of me. You need to offer some pretty
compelling performance reasons before I'd accept any part of it,
Changing a buffer you hold no lock on is a recipe for disaster.
Me too, in fact :-(.
The overall performance improvement
