On Fri, Mar 4, 2016 at 12:06 AM, Dilip Kumar <dilipbal...@gmail.com> wrote: > I have tried the approach of group extend, > > 1. We convert the extension lock to TryLock and if we get the lock then > extend by one block.2. > 2. If don't get the Lock then use the Group leader concep where only one > process will extend for all, Slight change from ProcArrayGroupClear is that > here other than satisfying the requested backend we Add some extra blocks in > FSM, say GroupSize*10. > 3. So Actually we can not get exact load but still we have some factor like > group size tell us exactly the contention size and we extend in multiple of > that.
This approach seems good to me, and the performance results look very positive. The nice thing about this is that there is not a user-configurable knob; the system automatically determines when larger extensions are needed, which will mean that real-world users are much more likely to benefit from this. I don't think it matters that this is a little faster or slower than an approach with a manual knob; what matter is that it is a huge improvement over unpatched master, and that it does not need a knob. The arbitrary constant of 10 is a little unsettling but I think we can live with it. -- 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
