In the current system, when a cursor is closed (and cursor caching is enabled on the connection), WT puts the cursor on a "cached" hash queue within the session. When session opens a cursor, we hash the URI to get the hash bucket and find any matching cached cursor, returning that to the caller (if the associated dhandle hasn't been dropped or closed.

This means that in every open_cursor call, we need to recompute the hash of the URI. This has some expense, of course, and open_cursor can be in the high performance path of certain workloads (ones that do for example: open, read, close).

Instead of this process, we could allow the application to "cache" the cursor directly (via an API call) and keep ownership of the cursor pointer, and then have a way to reopen the cursor (or maybe just start using it again?)

There are some details to work out, but as a starting point, we have an internal "cache" function on a cursor that could be exposed to callers and used directly for this purpose.