On Tue, Mar 8, 2016 at 7:23 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Mar 8, 2016 at 4:27 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > >> Hmm. Can we drive this off of the heavyweight lock manager's idea of > >> how big the relation extension lock wait queue is, instead of adding > >> more stuff to PGPROC? > > > > One idea to make it work without adding additional stuff in PGPROC is that > > after acquiring relation extension lock, check if there is any available > > block in fsm, if it founds any block, then release the lock and proceed, > > else extend the relation by one block and then check lock's wait queue size > > or number of lock requests (nRequested) and extend the relation further in > > proportion to wait queue size and then release the lock and proceed. Here, > > I think we can check for wait queue size even before extending the relation > > by one block. > > > > The benefit of doing it with PGPROC is that there will be relatively less > > number LockAcquire calls as compare to heavyweight lock approach, which I > > think should not matter much because we are planing to extend the relation > > in proportion to wait queue size (probably wait queue size * 10). > > I don't think switching relation extension from heavyweight locks to > lightweight locks is going to work. >
Sorry, but I am not suggesting to change it to lightweight locks. I am just suggesting how to make batching works with heavyweight locks as asked by you. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
