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>
> >> 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
> > 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
> > or number of lock requests (nRequested) and extend the relation further
> > proportion to wait queue size and then release the lock and proceed.
> > I think we can check for wait queue size even before extending the
> > by one block.
> >
> > The benefit of doing it with PGPROC is that there will be relatively
> > number LockAcquire calls as compare to heavyweight lock approach, which
> > think should not matter much because we are planing to extend the
> > 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

Reply via email to