On Thu, 13 Feb 2020 at 09:46, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Feb 11, 2020 at 9:13 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > I took a brief look through this patch. I agree with the fundamental > > idea that we shouldn't need to use the heavyweight lock manager for > > relation extension, since deadlock is not a concern and no backend > > should ever need to hold more than one such lock at once. But it feels > > to me like this particular solution is rather seriously overengineered. > > I would like to suggest that we do something similar to Robert Haas' > > excellent hack (daa7527af) for the !HAVE_SPINLOCK case in lmgr/spin.c, > > that is, > > > > * Create some predetermined number N of LWLocks for relation extension. > > * When we want to extend some relation R, choose one of those locks > > (say, R's relfilenode number mod N) and lock it. > > > > I am imagining something on the lines of BufferIOLWLockArray (here it > will be RelExtLWLockArray). The size (N) could MaxBackends or some > percentage of it (depending on testing) and indexing into an array > could be as suggested (R's relfilenode number mod N). We need to > initialize this during shared memory initialization. Then, to extend > the relation with multiple blocks at-a-time (as we do in > RelationAddExtraBlocks), we can either use the already proven > technique of group clear xid mechanism (see ProcArrayGroupClearXid) or > have an additional state in the RelExtLWLockArray which will keep the > count of waiters (as done in latest patch of Sawada-san [1]). We > might want to experiment with both approaches and see which yields > better results.
Thanks all for the suggestions. I have started working on the implementation based on the suggestion. I will post a patch for this in few days. -- Thanks and Regards Mahendra Singh Thalor EnterpriseDB: http://www.enterprisedb.com
