On Mon, Nov 20, 2017 at 5:19 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > Attached updated version patch. I've moved only relation extension > locks out of heavy-weight lock as per discussion so far. > > I've done a write-heavy benchmark on my laptop; loading 24kB data to > one table using COPY by 1 client, for 10 seconds. The through-put of > patched is 10% better than current HEAD. The result of 5 times is the > following. > > ----- PATCHED ----- > tps = 178.791515 (excluding connections establishing) > tps = 176.522693 (excluding connections establishing) > tps = 168.705442 (excluding connections establishing) > tps = 158.158009 (excluding connections establishing) > tps = 161.145709 (excluding connections establishing) > > ----- HEAD ----- > tps = 147.079803 (excluding connections establishing) > tps = 149.079540 (excluding connections establishing) > tps = 149.082275 (excluding connections establishing) > tps = 148.255376 (excluding connections establishing) > tps = 145.542552 (excluding connections establishing) > > Also I've done a micro-benchmark; calling LockRelationForExtension and > UnlockRelationForExtension tightly in order to measure the number of > lock/unlock cycles per second. The result is, > PATCHED = 3.95892e+06 (cycles/sec) > HEAD = 1.15284e+06 (cycles/sec) > The patched is 3 times faster than current HEAD. > > Attached updated patch and the function I used for micro-benchmark. > Please review it.
That's a nice speed-up. How about a preliminary patch that asserts that we never take another heavyweight lock while holding a relation extension lock? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company