On Mon, Mar 7, 2016 at 8:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > On Fri, Mar 4, 2016 at 11:49 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > I think one thing which needs more thoughts about this approach is that we > > need to maintain some number of slots so that group extend for different > > relations can happen in parallel. Do we want to provide simultaneous > > extension for 1, 2, 3, 4, 5 or more number of relations? I think providing > > it for three or four relations should be okay as higher the number we want > > to provide, bigger the size of PGPROC structure will be. > > 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).