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. It would mean, for example, that we lose the ability to service interrupts while extending a relation; not to mention that we lose scalability if many relations are being extended at once. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
