On 8 November 2018 at 15:01, Robert Haas <robertmh...@gmail.com> wrote: > Honestly, I *think* that the reason that find_all_inheritors() call is > there is because I had the idea that it was important to try to lock > partition hierarchies in the same order in all cases so as to avoid > spurious deadlocks. However, I don't think we're really achieving > that goal despite this code. If we arrive at this point having > already locked some relations, and then lock some more, based on > whatever got pruned, we're clearly not using a deterministic locking > order. So I think we could probably rip out the find_all_inheritors() > call here and change the NoLock in get_partition_dispatch_recurse() to > just take a lock. That's probably a worthwhile simplification and a > slight optimization regardless of anything else.
I'd not thought of the locks taken elsewhere case. I guess it just perhaps reduces the chances of a deadlock then. A "slight optimization" is one way to categorise it. There are some benchmarks you might find interesting in [1] and [2]. Patch 0002 does just what you mention. [1] https://www.postgresql.org/message-id/06524959-fda8-cff9-6151-728901897b79%40redhat.com [2] https://www.postgresql.org/message-id/CAKJS1f_1RJyFquuCKRFHTdcXqoPX-PYqAd7nz%3DGVBwvGh4a6xA%40mail.gmail.com -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
