On Wed, Dec 13, 2017 at 12:42 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Dec 11, 2017 at 4:10 PM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> Thank you for updating the patch. Here is two minor comments. >> >> + * we acquire the same relation extension lock repeatedly. nLocks is 0 is >> the >> + * number of times we've acquired that lock; >> >> Should it be "nLocks is the number of times we've acquired that lock:"? > > Yes. > >> + /* Remember lock held by this backend */ >> + held_relextlock.relid = relid; >> + held_relextlock.lock = relextlock; >> + held_relextlock.nLocks = 1; >> >> We set held_relextlock.relid and held_relextlock.lock again. Can we remove >> them? > > Yes. > > Can you also try the experiment Andres mentions: "Measure two COPYs to > relations on different filesystems, reduce N_RELEXTLOCK_ENTS to 1, and > measure performance.
Yes. I'll measure the performance on such environment. > Then increase the concurrency of the copies to > each relation." We want to see whether and how much this regresses > performance in that case. It simulates the case of a hash collision. > When we add extra blocks on a relation do we access to the disk? I guess we just call lseek and write and don't access to the disk. If so the performance degradation regression might not be much. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
