On Thu, Apr 26, 2018 at 3:30 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Apr 10, 2018 at 9:08 PM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> Never mind. There was a lot of items especially at the last CommitFest. >> >>> In terms of moving forward, I'd still like to hear what >>> Andres has to say about the comments I made on March 1st. >> >> Yeah, agreed. > > $ ping -n andres.freund > Request timeout for icmp_seq 0 > Request timeout for icmp_seq 1 > Request timeout for icmp_seq 2 > Request timeout for icmp_seq 3 > Request timeout for icmp_seq 4 > ^C > --- andres.freund ping statistics --- > 6 packets transmitted, 0 packets received, 100.0% packet loss > > Meanwhile, > https://www.postgresql.org/message-id/4c171ffe-e3ee-acc5-9066-a40d52bc5...@postgrespro.ru > shows that this patch has some benefits for other cases, which is a > point in favor IMHO.
Thank you for sharing. That's good to know. Andres pointed out the performance degradation due to hash collision when multiple loading. I think the point is that it happens at where users don't know. Therefore even if we make N_RELEXTLOCK_ENTS configurable parameter, since users don't know the hash collision they don't know when they should tune it. So it's just an idea but how about adding an SQL-callable function that returns the estimated number of lock waiters of the given relation? Since user knows how many processes are loading to the relation, if a returned value by the function is greater than the expected value user can know hash collision and will be able to start to consider to increase N_RELEXTLOCK_ENTS. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
