The updatable=false causes the column not to be in UPDATE statements which is beneficial for several reasons: * UPDATEs update less columns - thats always positive * Database vendor _might_ (and some do) take advantage of the affected columns list in UPDATE to eliminate even the need to check whether related index needs to be updated instead of checking whether the values match * There _might_ be optimizations on Hibernate side that would help. I'd need to dive more into actual details as I'd rather expect that it would show up if we used Hibernate caching. Yet the performance might actually improve even more by using @DynamicUpdate annotation on JPA entities. The @DynamicUpdate would do the job the Column.updatable does, in a less-prohibitive way, still allowing the updates but only including the changed fields in the result UPDATE. I'd imagine that would be most beneficial on UserEntity. --Hynek On Mon, Sep 11, 2017 at 4:04 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > This popped up in a support request, but we have a number of foreign > keys (with indexes) that are never changed, but yet are included in > update requests of those tables by Hibernate. It seems that a number > of databases (and Hibernate, although don't know if there is a setting > for that) will not check to see if the old value equals new value. > This can cause concurrency issues (db deadlock). I bet it is a big > performance issue too if indexes are updated as well. > > Should this be bumped to a priority for 3.4.1? I'll create a JIRA if so. > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- --Hynek