On Wed, Dec 13, 2017 at 12:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 11, 2017 at 4:10 PM, Masahiko Sawada <sawada.mshk@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