On Sun, 8 Jan 2006, Tom Lane wrote:
> > (1) The spinlock itself are light weight than the LWLock here and we
> > can reduce the lock contention a little bit in AbsorbFsyncRequests();
> Spinlock-based coding is inherently much more fragile than LWLock-based
> coding.  I'm against changing things in that direction unless a
> substantial performance improvement can be gained.  You didn't offer
> any evidence of improvement at all.
Yeah, only theoretically there is some marginal performance improvements.
Maybe you suggest we keep the LWLock but use the circular array part?

> > (2) Don't need the CRITICAL SECTION in AbsorbFsyncRequests() any more;
> Really?  I think this coding still breaks, rather badly, if
> RememberFsyncRequest fails.  Certainly the reasons for needing a
> critical section have nothing to do with what kind of lock is used.
Yeah, not related to lock. But I changed algorithm to circular array as
well and notice there is only one reader, so we can remove the requests
after the we are successfully done. In another word, if there is problem,
we never remove the unhanlded requests.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to