On Thu, Apr 26, 2018 at 2:10 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > 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.
I don't think that's a very useful suggestion. Changing N_RELEXTLOCK_ENTS requires a recompile, which is going to be impractical for most users. Even if we made it a GUC, we don't want users to have to tune stuff like this. If we actually think this is going to be a problem, we'd probably better rethink the desgin. I think the real question is whether the scenario is common enough to worry about. In practice, you'd have to be extremely unlucky to be doing many bulk loads at the same time that all happened to hash to the same bucket. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
