Hello. I had a brief look on this and have some comments on this. At Tue, 25 Feb 2020 07:53:26 +0000, "imai.yoshik...@fujitsu.com" <imai.yoshik...@fujitsu.com> wrote in > Thanks for Wang's mail, I noticed my 0002 patch was wrong from v3. > > Here, I attach correct patches. > > Also I will begin to do some benchmark with higher scale and higher number of > users and try to change stats reporting implementation to not affect > performance, which I couldn't have not started because of another tasks.
It uses its own hash implement. Aside from the appropriateness of having another implement of existing tool, in the first place hash works well for wide, sparse and uncertain set of keys. But they are in rather a dense and narrow set with certain and fixed members. It registers more than 200 entries but bucket size is 461. It would be needed to avoid colliisions, but seems a bit too wasting. It seems trying to avoid doing needless work when the feature is not activated by checking "if (wa_hash==NULL)", but the hash is created being filled with possible entries regardless of whether track_wait_timing is on or off. As the result pgstat_report_waitaccum_end calls pgstat_get_wa_entry tremendously frequently. This should be the reason for the recent benchmark result. I'm not sure such frequency of hash-searching is acceptable even if the feature is turned on. I think we need a smarter mapping scheme of events to entries. regards. -- Kyotaro Horiguchi NTT Open Source Software Center